volker.haas wrote:

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.

lambdav wrote:

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.

tari.ringeril wrote:

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.

volker.haas wrote:

(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 ;)

volker.haas wrote:

(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?

aklapper wrote:

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.haas wrote:

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).