Giuseppe Castagno wrote:
Philipp Lohmann - Sun Germany wrote:
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.
Sorry, but that is not the issue. We could easily export the font for
the control as well as for normal text. The issue is that we need a font
that has all glyphs that the user may enter into the reader app to be
displayed in that font, that is long after export.
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.
We already do that. But we're talking about a widget here that will be
modified in the reader app, long after it was exported by OOo ;-) We do
not know, what a use will enter here.
Kind regards, pl
--
If you give someone a program, you will frustrate them for a day;
if you teach them how to program, you will frustrate them for a lifetime.
-- Author unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
