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).
+1 embedding="auto|full|subset" (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. +1 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
