Re: OpenType CFF fonts…

[Alex Zepeda]

Glenn Adams wrote:

 From what I can tell, the CFF data primarily is related to outline 
presentations, which themselves have no relationship to kerning per se. 
So, the question seems one of how to employ the CFF outline 
representations in an OTF/CFF context, and how to pass through that 
outline data for embedding in the resultant PDF. Is that your 
understanding as well?


Okay, I've attached my second pass at this.  An /extremely/ naive CFF parser 
is included to handle the Unicode bits.  This should embed the CFF table into 
the PDF (fine with 1.2 or 1.3+ I believe), and sets up the mappings between 
the font's glyph names and unicode indexes… thus allowing the single byte 
additional encoding stuff to do its thing.  FOP did/does this with a separate 
Font dictionary referencing the same font-file, but with a ToUnicode entry 
attached.  It'll break for glyphs that reference more than one unicode index.


I used U+2190 and U+2196 as test cases.  In the font I used (FF Zwo OT Light) 
one uses a name that matches up fine with the proper unicode entity name, one 
does not.  One was giving me a box, one was working with no effort.  Now, they 
both work.


Oh… right… this time I fixed the Type1/Type1C references so that Acrobat will 
"properly" see this as a Type1C font and you'll get the neat red "a" logo.  It 
worked before, but Acrobat was mystified as to what type of font this really was.


- alex


fop-cff2.diff.bz2
Description: Binary data

Re: OpenType CFF fonts…

[Alex Zepeda]

Glenn Adams wrote:

 From what I can tell, the CFF data primarily is related to outline 
presentations, which themselves have no relationship to kerning per se. 
So, the question seems one of how to employ the CFF outline 
representations in an OTF/CFF context, and how to pass through that 
outline data for embedding in the resultant PDF. Is that your 
understanding as well?


Embedding is easy, just copy over the CFF table as-is.  Subsetting is more 
slightly more difficult, it's either rebuild a smaller CFF table or create a 
Type1 font from the chasrstrings.  CFF fonts with CID data are another matter, 
but could probably just be passed thru to the existing CID stuff.  For WinANSI 
that's all you need.


Getting a proper multibyte mapping of the non-CID stuff is where I'm at.  All 
of the existing multibyte bits in FOP assume CID.  Actually, the PDF docs seem 
to as well to some extent.  I think I can get away with stuffing GIDs into the 
cmap?  Quartz seems to include a differences table and a tounicode table for 
this font while properly identifying it as a Type1C.


Exposing the rest of the data is trivial.  It's all going to be index or dict 
format.


- alex

Re: OpenType CFF fonts…

[Glenn Adams]

As far as kerning is concerned, for the existing TTF and OTF support,
positioning is handled at the TextLayoutManager layer in combination with
rendering instructions through the IF rendering layer. Prior to
Temp_ComplexScripts (and current in the trunk), kerning is performed only
when a 'kern' table is present and has not been disabled. With the addition
of the GPOS table support in Temp_ComplexScripts, a very rich set of
context-sensitive kerning (in both X and Y axes) is supported. If a font has
a GPOS table, then any 'kern' table is ignored.

>From what I can tell, the CFF data primarily is related to outline
presentations, which themselves have no relationship to kerning per se. So,
the question seems one of how to employ the CFF outline representations in
an OTF/CFF context, and how to pass through that outline data for embedding
in the resultant PDF. Is that your understanding as well?

Regards,
Glenn

On Fri, Mar 4, 2011 at 12:12 AM, Alex Zepeda  wrote:

> Glenn Adams wrote:
>
>> It may be useful to wait until the Temp_ComplexScripts branch is merged
>> into trunk to decide how to proceed with CFF. It is possible my client would
>> like me to take a stab at CFF, so I may be able to add that to my task list.
>>
>
> Perhaps.  Exposing the CFF data is trivial tho.  It's knowing what to do
> with it (ex: parsing the charstrings to get extended kerning info) that's
> more difficult.  Right now I'm thinking I should be able to take the glyph
> (name to gid) index and create a Type1-esque cmap.  I've already got the
> code to parse indexes (incl. the gid to glyph name one), so.
>
> What sort of timeframe were you looking at for completing the
> Temp_ComplexScripts branch?
>
> - alex
>

Re: OpenType CFF fonts…

[Alex Zepeda]

Glenn Adams wrote:
It may be useful to wait until the Temp_ComplexScripts branch is merged 
into trunk to decide how to proceed with CFF. It is possible my client 
would like me to take a stab at CFF, so I may be able to add that to my 
task list.


Perhaps.  Exposing the CFF data is trivial tho.  It's knowing what to do with 
it (ex: parsing the charstrings to get extended kerning info) that's more 
difficult.  Right now I'm thinking I should be able to take the glyph (name to 
gid) index and create a Type1-esque cmap.  I've already got the code to parse 
indexes (incl. the gid to glyph name one), so.


What sort of timeframe were you looking at for completing the 
Temp_ComplexScripts branch?


- alex

Re: OpenType CFF fonts…

[Glenn Adams]

It may be useful to wait until the Temp_ComplexScripts branch is merged into
trunk to decide how to proceed with CFF. It is possible my client would like
me to take a stab at CFF, so I may be able to add that to my task list.

G.

On Thu, Mar 3, 2011 at 7:03 PM, Alex Zepeda  wrote:

> Glenn Adams wrote:
>
>> Actually, many fonts from MSFT, Adobe, and others are starting to take
>> advantage of the OpenType GSUB/GPOS and related advanced typographic tables,
>> even for fonts used with Latin and other Western scripts. Since (generic)
>> support for these mechanisms has been added in the Temp_ComplexScripts
>> branch, it is likely the same mechanisms can be used for CFF that reuse
>> these or similar features, though I haven't investigated it.
>>
>
> Fair enough.  I'm still bummed that Apple's Pages has better OTF support
> than Quark 8.  FFS.  In any case, I guess the big organizational question
> is: does this all get shoved in the TrueType parsing classes?  Or is it time
> to split things up and devise something quick but more robust than file
> extension to differentiate the two?
>
> - alex
>

Re: OpenType CFF fonts…

[Alex Zepeda]

Glenn Adams wrote:
Actually, many fonts from MSFT, Adobe, and others are starting to take 
advantage of the OpenType GSUB/GPOS and related advanced typographic 
tables, even for fonts used with Latin and other Western scripts. Since 
(generic) support for these mechanisms has been added in the 
Temp_ComplexScripts branch, it is likely the same mechanisms can be used 
for CFF that reuse these or similar features, though I haven't 
investigated it.


Fair enough.  I'm still bummed that Apple's Pages has better OTF support than 
Quark 8.  FFS.  In any case, I guess the big organizational question is: does 
this all get shoved in the TrueType parsing classes?  Or is it time to split 
things up and devise something quick but more robust than file extension to 
differentiate the two?


- alex

Re: OpenType CFF fonts…

[Glenn Adams]

Actually, many fonts from MSFT, Adobe, and others are starting to take
advantage of the OpenType GSUB/GPOS and related advanced typographic tables,
even for fonts used with Latin and other Western scripts. Since (generic)
support for these mechanisms has been added in the Temp_ComplexScripts
branch, it is likely the same mechanisms can be used for CFF that reuse
these or similar features, though I haven't investigated it.

G.

On Thu, Mar 3, 2011 at 3:07 PM, Alex Zepeda  wrote:

> Andreas Delmelle wrote:
>
>  If I judge correctly, taking full advantage of CFF would mean that,
>> instead
>> of just asking the font what the width is of a single given char, we would
>> pass it a sequence of chars and rely on the font code to figure out the
>> impact of merging/ligatures etc.
>>
>
> While I wrote a quick CFF parser for TTFSubSetFile (more of a false start,
> altho potentially useful for getting away from WinANSI), I haven't looked at
> the Type 2 spec in great detail.
>
> Given how lackluster OpenType support is in most applications to this day,
> I wonder how many foundries are going to include such complex features as
> advanced kerning. I didn't even try to parse the charstrings or grok the
> added Type 2 operators.  Altho it shouldn't be too hard to write a
> rudimentary charstring parser to get some idea of which fonts do and don't
> have this info.  At first glance, the FontShop guys seem to be pretty great
> at utilising the OpenType features to their fullest, but…
>
> I don't have a real need because I simply don't have particularly complex
> formatting needs.  It's all English, and mostly tabular layouts.  Nothing
> demanding.
>
> - alex
>

Re: OpenType CFF fonts…

[Alex Zepeda]

Andreas Delmelle wrote:


If I judge correctly, taking full advantage of CFF would mean that, instead
of just asking the font what the width is of a single given char, we would
pass it a sequence of chars and rely on the font code to figure out the
impact of merging/ligatures etc.


While I wrote a quick CFF parser for TTFSubSetFile (more of a false start, 
altho potentially useful for getting away from WinANSI), I haven't looked at 
the Type 2 spec in great detail.


Given how lackluster OpenType support is in most applications to this day, I 
wonder how many foundries are going to include such complex features as 
advanced kerning. I didn't even try to parse the charstrings or grok the added 
Type 2 operators.  Altho it shouldn't be too hard to write a rudimentary 
charstring parser to get some idea of which fonts do and don't have this info. 
 At first glance, the FontShop guys seem to be pretty great at utilising the 
OpenType features to their fullest, but…


I don't have a real need because I simply don't have particularly complex 
formatting needs.  It's all English, and mostly tabular layouts.  Nothing 
demanding.


- alex

Re: OpenType CFF fonts…

[Andreas Delmelle]

On 03 Mar 2011, at 22:07, Alex Zepeda wrote:

Hi Alex

> Over the years I've kept an eye on the lists.  Every year it seems like 
> someone's interested, and someone's willing.  Right now I guess I don't know 
> if anyone is actively working on /proper/ CFF support.  So hopefully I'm not 
> stepping on anyone's toes.

Hmm, stepping on toes would imply that you are bothering someone. I would be 
surprised if that were the case here. :-)

The question popped up again recently, but I am unaware of anyone having taken 
specific actions in that direction since then --apart from you, that is.

> I've attached a patch with a quick, dirty, and naive hack.  For OTF/CFF 
> fonts, it embeds the CFF table wholesale in the PDF as a FontFile3 with the 
> proper Subset fields.  This gets you WinAnsi characters only.  Pretty sure 
> there's no kerning in there either.  But it's a start.  I guess I'll be 
> looking into what it'll take to get a proper encoding map all setup.

Indeed, a good start. 
The *real* fun would begin, however, if the layout engine could take advantage 
of the additional functionality offered by CFF as well.
Out of pure curiosity, I dove into the related specs recently, and noticed that 
CFF was meant (mainly) to address two shortcomings of Type 1 fonts:
- as the name implies, it is meant to be more 'Compact'
- it is meant to satisfy requirements of more complex scripts: where Type 1 
only has kerning, CFF has another set of functions at its disposal to define 
and describe more complex interactions between glyphs (not limited to two). It 
is centered all around Type 2 charstrings.

If I judge correctly, taking full advantage of CFF would mean that, instead of 
just asking the font what the width is of a single given char, we would pass it 
a sequence of chars and rely on the font code to figure out the impact of 
merging/ligatures etc.

> My ultimate desire with FOP is to see access alternate glyphs.  I'm using 
> FF's Zwo (yeah, yeah, next time just buy the TrueType version — but even 
> Quark /kinda/ works with these things) and would like to access the salt 
> and/or ss01 glyphs.

Thanks for sharing the ideas!


Regards,

Andreas
---

Re: OpenType CFF fonts…

[Alex Zepeda]

Alex Zepeda wrote:

I've attached a patch with a quick, dirty, and naive hack.  For OTF/CFF 
fonts, it embeds the CFF table wholesale in the PDF as a FontFile3 with 
the proper Subset fields.  This gets you WinAnsi characters only.  
Pretty sure there's no kerning in there either.  But it's a start.  I 
guess I'll be looking into what it'll take to get a proper encoding map 
all setup.


P.S.  According to , embedding the CFF 
table should work just fine from PDF 1.2 on up.  For my quick test it works 
with OSX.6's Preview.app, Adobe Reader X, and Chrome 9.0.597.102.


- alex