Philipp Lohmann - Sun Germany wrote:
Giuseppe Castagno wrote:
mm..., and if the PDF filter could export font clever-wise? I mean,
using the same font the user provided for the control, if that exist
in the OOo document, or using some kind of font fall back, for example
the same provided by the display rendering? I think there is some kind
of fall back in the display rendering code of OOo, ain't it?
You can only set one font in the PDF widget appearance stream. The
fallback would have to be done by the reader app; and even if that were
possible (possibly CID fonts can do that), rendering some glyphs with
one font and other glyphs with another font will just end up looking
like crap (as it does when OOo's font fallback needs to replace single
glyphs in a font).
I was thinking of doing some kind of fall back while exporting,
supposing that the control font is one kind only, then embed it as it
were a document font.
In any case if the fonts are mixed up crappy in OOo, the filter should
do the fall back to the standard, as it seems doing now.
However currently we do not have a solution for locales outside
WinAnsiEncoding at all. I think at least for eastern fonts we will not
come around using a system font not contained in the PDF file (we cannot
download a font containing 10000 glyphs for chinese for example, such a
font would alone have some 40 MB or so).
In this case, shouldn't it be possible to embed in the PDF only the
glyphs used in the document? I don't know if this is possible, I have to
read chapter 5 of PDF spec (1.4) to build up a knowledge of text, font,
glyphs, quite a reading! Not to mention the appendices you are
continually pointed to.
--
Kind Regards,
Giuseppe Castagno
Acca Esse http://www.acca-esse.eu
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
