On 18.11.2010 16:05:25 mehdi houshmand wrote:
> All that being said, I could implement my initial proposal, obviously
> it would have to be user friendly and not conflict with the settings
> already available, so maybe a parameter called "embedding" with two
> possible values, "full" and "subset" (since the "none" is already
> covered by referenced fonts).

(default: auto, where auto=type1:full/ttf:subset like we have for PDF).

Also, we have to keep in mind that with the current code, embedding the
full font (in /snfts) will likely result in the same problem as before I
switched to the GlyphDirectory approach for subset TTF. Might make sense
to switch that, too.

> As for the unique prefix for the font name, may I suggest moving it
> from the font level (o.a.f.fonts.MultiByteFont) to PS level (maybe
> implemented in somewhere like o.a.f.render.ps.PSFontUtils), this would
> allow a more intelligent implementation since PS and PDF don't have
> the same requirements in this case since PDF prefixes only need to be
> unique to the document.


And to answer Chris' question:

On 17.11.2010 09:42:19 Chris Bowditch wrote:
> So now where does 
> that leave us in terms of the configuration and/or implementation details?

- I think we agree that the regex mechanism for referencing is useful.

- FOP should automatically switch to single-byte encoding if referencing
is activated for a font (like we already do for PDF output). That
increases the probability that a pre-installed font is going to work
(because it probably has a /CharStrings dict).

- We can switch between single-byte and cid with the encoding attribute
which is useful, but mostly an advanced option for people who know what
they are doing.

- For PDF we have full embedding for Type 1 and CID subset embedding for
TTF by default. I think that's a good default especially since we don't
support Type1 subsetting. That behaviour should be applied to PostScript,
too, IMO.

- Now, for some advanced use cases (PS post-processing), we need full
TTF embedding for PS output. Mehdi's embedding="full" will do that trick,
but the /sfnts boundary problem needs to be sorted out (possibly by also
switching to /GlyphDirectory there).

- Obviously, embedding="subset" with a Type 1 font currently needs to
result in a "NYI" exception.

Just a thought: we could think about an encoding="unicode" option which
would use 16-bit Unicode values as character codes (instead of the
direct glyph addressing by index with Identity-H). That would mean
generating appropriate CMaps. I'm not sure if it would solve any problem
other than make debugging/reading PS files easier. Of course, it would
not allow Unicode characters above 0xFFFF. As I said: just a thought.

Jeremias Maerki

Reply via email to