[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    Re: TrueType Font Embedding
From:       mehdi houshmand <med1985 () gmail ! com>
Date:       2010-11-23 10:51:37
Message-ID: AANLkTimBVfB0T3156XYd1X7AxeEQubc71HrXEk=n0KAC () mail ! gmail ! com
[Download RAW message or body]

Hi Jeremias,

Without trying to flog a dead horse here, would you mind if I changed
your TTFSubSetFile.GlpyhHandler interface by putting in the
implementation from PSFontUtils (i.e. making it an inner class rather
than an interface).  My reason for this change is that I'm creating
unit tests, so that I can implement the changes we discussed above
confidently. I do appreciate that this would be slightly
counter-intuitive but I do think my reason is a valid one since unit
tests (and regression testing) is one area that the fonts package is
in dire need of. Anyway, is this something you have any particular
objections to?

By the way, I'd like to think that generating "proper" CMaps would be
the "correct" solution, if there is a correct solution. I'm not sure
how difficult that would be, I'm still a little green in terms of
fonts and how PS/PDF interpret them.

Mehdi

On 19 November 2010 08:00, Jeremias Maerki <dev@jeremias-maerki.ch> wrote:
> 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
>
>
[prev in list] [next in list] [prev in thread] [next in thread]