Hi Guys,
Just some remarks:
\u0092 is not a valid xhtml character entity reference [1] (ie it is not defined
by the xhtml 1.0 DTD), so IMO MPIR should not use it in the first place. I think
that \u0027 (apos) should be used instead but MPIR-136 states that this leads to
test failures? I'd guess that this should be fixed instead?
In any case, I also don't like it if we arbitrarily re-write some characters just
to work around a bug elsewhere. If a user wants to use this entity (ie declares it
in an external DTD and gets the right font), then he may very well complain if it
gets replaced by a 'too clever' pdf plugin.
Finally, in case you are not aware, there is a test document in the pdf plugin to
render all xhtml entities, check the file target/test-output/pdf/unnamed.pdf. As
you see there are a few characters rendered as # (specifically for me: U+2032,
U+2033, U+203E, U+2308, U+2309, U+230A, U+230B, 7 out of 253). I always attributed
that to missing fonts but maybe it's actually a fop issue..
Cheers,
-Lukas
[1]
http://en.wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references
Vincent Siveton wrote:
Hi Hervé,
2009/9/5 Hervé BOUTEMY <[email protected]>:
I'm not convinced this is a good idea: MPIR is fixed now, but this hack will
prevent anybody to output \u0092 when it is the real character they want.
Using \u0092 char will be displayed as # in the pdf so I don't think
user want to use this char.
MPIR 2.1.x uses \u0092 instead of quote due to an old hack MPIR-59 so
IMHO we need to add this workaround to correctly generate PDF in
French.
Cheers,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
