Last modified: 2013-03-25 13:11:03 UTC
When using Collection to generate a PDF version of pages, the rendering have layout problems. It should respect the same layout as when viewing the pages using a web browser otherwise we cannot rely on this extension to render pages properly. For an example, see https://fr.wikibooks.org/wiki/S%27initier_au_boulier_en_10_le%C3%A7ons
I checked the resulting PDF of the above mentioned article. For me the PDF looks great. The PDF can't look identical to the result in the browser because of different canvas sizes, fonts etc. Furthermore a PDF is rendered on a paginated medium whereas the monitor has an arbitrarily large height (scrolling!) - therefore the PDF will never look identical to the browser version.
It looks better than before because I corrected the ChiffreBoulier template which used the <br> HTML tag. With previous version of the model, all elements were on the same horizontal line, which overflowed the page width. PDF rendering can be the same as browser. There is no technical problem to respect the same layout as browser : * Font size is not the question about layout of elements. * Different canvas size is only a matter of scaling like when resizing browser window. * The arbitrarily large height only need to be cut into pages at proper location within the text. In case of problems, there should be a special tag in the wiki source to indicate where page can be cut if the default cut location is not appropriate. As the layout is currently not the same as the wiki page, we have to modify multiples pages before making any collection. That make this extension unreliable and unusable currently.
I also have several problems with pdf rendering. I'm not sure if I should create a new bug report or post those here. * When quoting several references in the same part of the text, converting to pdf introduces a blank space before the comma separating them, like "[1] , [2]", which is not correct considering typography: "[1], [2]", see for example http://fr.wikibooks.org/wiki/Cristallographie_g%C3%A9om%C3%A9trique/Introduction where there are two occurences of the problem. * When using a picture aligned to the right and a math formula in the text to the left of it, the pdf version places the formula below the picture, regardless of the length of the formula. I have obtained bad layouts because of this, with huge blank spaces at the left of the picture, although there was more than enough place to fit the formula there. I have managed to improve the layout by adding text above the formulas but we shouldn't have to change pages only so that the pdf version looks acceptable. * Most bothering, the pdf doesn't render texts like <span style="text-decoration:overline">1</span>, instead of <span style="text-decoration:overline">1</span> I see 1 in the pdf version. That's really troublesome because in all articles about crystallography, and in all textbooks outside the wikimedia projects, we describe directions in crystals as [<span style="text-decoration:overline">1</span>11] (for example), the direction [111] is a completely different one. See http://fr.wikibooks.org/wiki/Cristallographie_g%C3%A9om%C3%A9trique/R%C3%A9seaux_de_Bravais or http://fr.wikipedia.org/wiki/R%C3%A9seau_de_Bravais - these are by far not the only pages using this notation.
(In reply to comment #3) > I also have several problems with pdf rendering. I'm not sure if I should > create a new bug report or post those here. In the future please do so! > * When quoting several references in the same part of the text, converting to > pdf introduces a blank space before the comma separating them, like "[1] , > [2]", which is not correct considering typography: "[1], [2]", see for example > http://fr.wikibooks.org/wiki/Cristallographie_g%C3%A9om%C3%A9trique/Introduction > where there are two occurences of the problem. Thanks for pointing out this issue - I have fixed this with: https://github.com/pediapress/mwlib.rl/commit/2c8f579ddbe74c822701e24dab838c781a8e7c53 I'll update the render servers later > * When using a picture aligned to the right and a math formula in the text to > the left of it, the pdf version places the formula below the picture, > regardless of the length of the formula. I have obtained bad layouts because of > this, with huge blank spaces at the left of the picture, although there was > more than enough place to fit the formula there. I have managed to improve the > layout by adding text above the formulas but we shouldn't have to change pages > only so that the pdf version looks acceptable. I have fixed this issue as well: https://github.com/pediapress/mwlib.rl/commit/da5af1abb98216b5c993cab597398e3d8ab1228c https://github.com/pediapress/mwlib.rl/commit/b405f2c864aa25903d7f8f5494ee4d40d4bb723e > * Most bothering, the pdf doesn't render texts like <span > style="text-decoration:overline">1</span>, instead of <span > style="text-decoration:overline">1</span> I see 1 in the pdf version. That's > really troublesome because in all articles about crystallography, and in all > textbooks outside the wikimedia projects, we describe directions in crystals as > [<span style="text-decoration:overline">1</span>11] (for example), the > direction [111] is a completely different one. See > http://fr.wikibooks.org/wiki/Cristallographie_g%C3%A9om%C3%A9trique/R%C3%A9seaux_de_Bravais > or http://fr.wikipedia.org/wiki/R%C3%A9seau_de_Bravais - these are by far not > the only pages using this notation. The problem with overlines is that this is simply not supported by the pdf-framework we are using. I'll see if I can add support for overlines with a reasonable amount of work. Just for the record: a workaround would be to use the "Combining Overline" character as described here: http://en.wikipedia.org/wiki/Overline I know that this is not really a solution to the problem ;)
(In reply to comment #4) > (In reply to comment #3) > > * Most bothering, the pdf doesn't render texts like <span > > style="text-decoration:overline">1</span>, instead of <span > > style="text-decoration:overline">1</span> I see 1 in the pdf version. That's > > really troublesome because in all articles about crystallography, and in all > > textbooks outside the wikimedia projects, we describe directions in crystals as > > [<span style="text-decoration:overline">1</span>11] (for example), the > > direction [111] is a completely different one. See > > http://fr.wikibooks.org/wiki/Cristallographie_g%C3%A9om%C3%A9trique/R%C3%A9seaux_de_Bravais > > or http://fr.wikipedia.org/wiki/R%C3%A9seau_de_Bravais - these are by far not > > the only pages using this notation. > > The problem with overlines is that this is simply not supported by the > pdf-framework we are using. I'll see if I can add support for overlines with a > reasonable amount of work. > > Just for the record: a workaround would be to use the "Combining Overline" > character as described here: http://en.wikipedia.org/wiki/Overline > I know that this is not really a solution to the problem ;) I just checked the reportlab source code and came to the conclusion that I can't add overline support. A solution for you could be the following: create a print template for the overline template. The overline print template could then use the "combinging overline" char to render overlines in the PDF
It looks like the workaround is to use <math>[\bar{1}11]</math> Has the lack of overline support been logged as a bug in the relevant software package?
Wondering what to do with this bug report. Seeing DavidL's comment 2 this sounds mostly like an enhancement request or even WONTFIX (but maybe I missed something important?). In general, filing one problem per report and describing the problem ("rendering problems" is too vague) is very welcome, also see https://www.mediawiki.org/wiki/How_to_report_a_bug Volker: > Has the lack of overline support been logged as a bug in the relevant > software package?
> > > Volker: > > > Has the lack of overline support been logged as a bug in the relevant > > software package? No, but I just mentioned the problem on the reportlab mailing list (since there is no bugtracker).
