Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> In the case of CFF, we get these values from `hhea' or `OS/2'. This
> includes a "line gap" value. But for Type 1, we can only obtain the
> ascender/descender values and not the line gap, as there is no such
> field in AFM.  I did even try editing the AFM file by hand in an
> attempt to get the lines to match up (in ftview's waterfall view),
> to no avail.

Indeed, font editors provide an educated guess for the line gap value
if converting from Type 1 to, say, CFF.

> So, regardless of the converter, we cannot obtain the same line
> spacing between Type 1 and CFF versions of the same font. In fact, I
> think most typesetting applications override line spacing anyway, so
> the importance of keeping this consistent is questionable. A
> reasonable compromise, then, is to just keep the current behaviour
> which is to use the bbox values.

Yes.

> In any case, the hinting seems to be consistent between the two, so I
> think the new interpreter is working fine.

Congrats :-)

> The metrics issues are from the module loading the glyph and may be
> bugs that need to be fixed later on.  Note that it only happens with
> fonts converted from CFF to Type 1, not between Type 1 old and Type
> 1 new, so this is a separate issue that exists on master branch as
> well.  For now, I'll move on to adding CID support and cleaning up
> the other changes first.

Thanks!


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

> OTOH, surely global ascender /descender is not related to line-spacing at all?

I guess it depends on the application... some fonts are not designed
for multi-line typesetting, esp. artistic ones like Zapfino, and the
ascender/descenders probably reflect this. However, FreeType does use
the ( ascender - descender ) (for cff) or the bbox (for type1) value
to calculate vertical advance.

In the case of CFF, we get these values from `hhea' or `OS/2'. This
includes a "line gap" value. But for Type 1, we can only obtain the
ascender/descender values and not the line gap, as there is no such
field in AFM. I did even try editing the AFM file by hand in an
attempt to get the lines to match up (in ftview's waterfall view), to
no avail.

So, regardless of the converter, we cannot obtain the same line
spacing between Type 1 and CFF versions of the same font. In fact, I
think most typesetting applications override line spacing anyway, so
the importance of keeping this consistent is questionable. A
reasonable compromise, then, is to just keep the current behaviour
which is to use the bbox values.

In any case, the hinting seems to be consistent between the two, so I
think the new interpreter is working fine. The metrics issues are from
the module loading the glyph and may be bugs that need to be fixed
later on. Note that it only happens with fonts converted from CFF to
Type 1, not between Type 1 old and Type 1 new, so this is a separate
issue that exists on master branch as well. For now, I'll move on to
adding CID support and cleaning up the other changes first.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Hin-Tak Leung]

On Mon, 17/7/17, Werner LEMBERG  wrote:
 
> Looks like a buglet (or feature) in
> FontForge.  It seems that the
> ascender and
> descender values are based on the font's bboxes of
> all
> glyphs (taking probably the maximum and
> minimum, respectively).
> However, the OS/2
> values should be taken literally instead.

I'd say it is probably a feature of FontForge rather than a bug, to actually 
sum all the bound boxes. OTOH, surely global ascender /descender is not related 
to line-spacing at all? It is entirely conceivable, though extremely unlikely, 
that a font is, by design, having a lot of hanging-below and sticking-above 
bits, or having very line-spacings within nothing much between.

I think the Zapfino font ( https://en.wikipedia.org/wiki/Zapfino ) is a good 
illustration of the "lots of hanging-below and sticking-above bits" idea...

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

> fontforge does output afm. But I did not include them in the tar ball
> as the intended purpose (TeX) of outcome does need them. If you use
> the fontforge script itself, or go a bit further later in that mail
> archive for the one about 'Combo script', and run the script itself
> with fontforge, it should generate afm also. It is the last line. You
> might be able to adapt that for non-CJK font too. It takes about 25
> minutes to run on my hardware to convert the 25M(?) of CJK font so be
> patient; and takes about 1.5GB of ram - fontforge is quite hungry but
> we are talking about loading a large cjk font . ascii fonts will be
> quicker and use less resources.

I see. I'll try converting a CJK font on my own once I get the Latin
glyphs looking right first.

So I tried converting SourceSansPro-Regular using fontforge. In the
process also fixing problems with the flex feature (which I've just
pushed)

Looking at the metrics, though...

Converted (AFM)
  StartFontMetrics 2.0
  Comment Generated by FontForge 20120731
  Comment Creation Date: Mon Jul 17 15:39:50 2017
  FontName SourceSansPro-Regular
  FullName Source Sans Pro
  FamilyName Source Sans Pro
  Weight Book
  Notice (Copyright 2010, 2012, 2014 Adobe Systems Incorporated
(http://www.adobe.com/), with Reserved Font Name 'Source'.)
  ItalicAngle 0
  IsFixedPitch false
  UnderlinePosition -50
  UnderlineThickness 50
  Version 2.0
  EncodingScheme AdobeStandardEncoding
  FontBBox -454 -293 2159 968
  CapHeight 656
  XHeight 486
  Ascender 712
  Descender -205

Original (OS/2)
  





  

The relevant fields in the AFM are, I believe, `Ascender' and
`Descender'. However, these do not match `sTypoAscender' and
`sTypoDescender', which is what `cffgload.c' uses to set the vertical
advance, and I can't find a way to combine the other values to make
these. I'm not sure why fontforge output those values...

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Hin-Tak Leung]

On Mon, 17/7/17, Ewald Hew  wrote:

> Trying with
> what font Hin-Tak provided didn't give any extra
> clues
> unfortunately, and the hints in that
> one appear to be broken too -
> they
> didn't show up in the interpreter debug trace.
 
> I feel that the cause for the
> line spacing lies with the font
> converter,
> and there's no other way to obtain the same vertical
> advance without those tables.
 
fontforge does output afm. But I did not include them in the tar ball as the 
intended purpose (TeX) of outcome does need them. If you use the fontforge 
script itself, or go a bit further later in that mail archive for the one about 
'Combo script', and run the script itself with fontforge, it should generate 
afm also. It is the last line. You might be able to adapt that for non-CJK font 
too. It takes about 25 minutes to run on my hardware to convert the 25M(?) of 
CJK font so be patient; and takes about 1.5GB of ram - fontforge is quite 
hungry but we are talking about loading a large cjk font . ascii fonts will be 
quicker and use less resources.  

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> I did a:
> 
>   $ ls | xargs -L1 detype1 | grep "stem "
> 
> and the result was empty. `detype1' is from the AFDKO. I tried the
> same with `t1disasm' too, none either. I guess this one doesn't have
> hints...

Probably, yes.

>> I suppose that the Type1->CFF engine transition in FreeType is not
>> affected by AFM handling (via `FT_Attach_File'), right?
> 
> I presume not; fonts with AFM data are still being handled properly,
> such as with Courier in one of the gifs I posted.

OK, thanks.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

> A call to `t1disasm' from the `t1utils' package might give clues if
> you compare the Type1 file hints with the ones created by the `ttx'
> disassembler.

I did a:

  $ ls | xargs -L1 detype1 | grep "stem "

and the result was empty. `detype1' is from the AFDKO. I tried the
same with `t1disasm' too, none either. I guess this one doesn't have
hints...

> FontForge is able to output AFM files also while exporting Type 1
> fonts; maybe this helps.

Thanks, I'll try that.

> I suppose that the Type1->CFF engine transition in FreeType is not
> affected by AFM handling (via `FT_Attach_File'), right?

I presume not; fonts with AFM data are still being handled properly,
such as with Courier in one of the gifs I posted.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

>> Interesting.  It seems to show that the problem is not in the
>> hinting but at a more fundamental level.
> 
> Ugh. This was a really simple mistake, and I'd missed it
> completely. I had set the origin point wrongly in `seac' for the
> base character.  Fixed.

Good!

> It turns out that, at least for the Source Sans font, when converted
> to Type 1, the OS/2 table was lost, which makes the line spacing
> wrong.  I think that needs .afm output, which this converter doesn't
> seem to support.

OK.

> Trying with what font Hin-Tak provided didn't give any extra clues
> unfortunately, and the hints in that one appear to be broken too -
> they didn't show up in the interpreter debug trace.

A call to `t1disasm' from the `t1utils' package might give clues if
you compare the Type1 file hints with the ones created by the `ttx'
disassembler.

> I feel that the cause for the line spacing lies with the font
> converter, and there's no other way to obtain the same vertical
> advance without those tables.

The AFM specification can be found in Adobe Technical Note #5004.

  http://www.adobe.com/content/dam/Adobe/en/devnet/font/pdfs/5004.AFM_Spec.pdf

FontForge is able to output AFM files also while exporting Type 1
fonts; maybe this helps.

I suppose that the Type1->CFF engine transition in FreeType is not
affected by AFM handling (via `FT_Attach_File'), right?


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

>> The first two are between hinting on and off for Type 1.  Notice how
>> the base glyphs of accented characters shift about regardless.
>
> Interesting.  It seems to show that the problem is not in the hinting
> but at a more fundamental level.

Ugh. This was a really simple mistake, and I'd missed it completely. I
had set the origin point wrongly in `seac' for the base character.
Fixed.

>> The third is for CFF converted to Type 1.  Notice how the line
>> spacing changes in discrete steps above a certain font size.  For
>> 26~29pt, it shifts downwards one step, and for 30pt it seems to
>> shift a little bit more.
>
> Ditto.

The cause for this was harder to find. It turns out that, at least for
the Source Sans font, when converted to Type 1, the OS/2 table was
lost, which makes the line spacing wrong. I think that needs .afm
output, which this converter doesn't seem to support.

Trying with what font Hin-Tak provided didn't give any extra clues
unfortunately, and the hints in that one appear to be broken too -
they didn't show up in the interpreter debug trace.

I feel that the cause for the line spacing lies with the font
converter, and there's no other way to obtain the same vertical
advance without those tables.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> The first two are between hinting on and off for Type 1.  Notice how
> the base glyphs of accented characters shift about regardless.

Interesting.  It seems to show that the problem is not in the hinting
but at a more fundamental level.

> The third is for CFF converted to Type 1.  Notice how the line
> spacing changes in discrete steps above a certain font size.  For
> 26~29pt, it shifts downwards one step, and for 30pt it seems to
> shift a little bit more.

Ditto.

> I compared the two code paths, especially the parts to do with
> metrics, but could not find what changed between that would cause
> this.  My current guess is that some metric info is not being passed
> properly from the interpreter out to the module loading the glyph,
> but this is proving hard to debug via comparing printouts of
> numbers.

In such situations, I run

  FT2_DEBUG=any:7 ftview ... &> ftview.log,

adjusting its command line arguments as necessary so that the number
of key presses needed to show the desired difference stays as small as
possible.  I then compare the log files with `colordiff', using option
`-x PATTERN' repeatedly to suppress output of irrelevant lines.  You
might also adjust the value FT2_DEBUG to suppress more irrelevant
data.

If this doesn't give sufficient information I start adding tracing
messages until I see the difference – in many cases it makes even
sense to add the `resolving' tracing message upstream.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

> The third is for CFF converted to Type 1. Notice how the line spacing
> changes in discrete steps above a certain font size. For 26~29pt, it
> shifts downwards one step, and for 30pt it seems to shift a little bit
> more.

Addendum:
Worded this wrongly, should have said that only 26pt and 30pt appear
to change, while the rest of the spacings remain consistent between
CFF and Type 1. This is very strange and suggests some kind of
rounding error?


Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

Thanks all for the valuable info! Sorry for the lack of reply.

I had fixed hinting as I realised the interpreter was actually not
respecting mid-charstring hints due to the hintmask.

>> While I am not aware of any open source Type 1 fonts from Adobe, I'd
>> suggest looking into converting some CFF fonts to Type 1 for
>> testing.
>
> This sounds very sensible!  Ewald, can you do that?

Yes, I'd already tried converting one of the Source family fonts using
the `tx' utillity. Doing this I found that the placement of glyphs
seemed wrong, which I've been trying to figure out.

Refer to the attached gifs.

The first two are between hinting on and off for Type 1. Notice how
the base glyphs of accented characters shift about regardless.
The third is for CFF converted to Type 1. Notice how the line spacing
changes in discrete steps above a certain font size. For 26~29pt, it
shifts downwards one step, and for 30pt it seems to shift a little bit
more.

I compared the two code paths, especially the parts to do with
metrics, but could not find what changed between that would cause
this. My current guess is that some metric info is not being passed
properly from the interpreter out to the module loading the glyph, but
this is proving hard to debug via comparing printouts of numbers.

Ewald
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Dave Arnold]

Adobe has produced several Open Source CFF fonts that should be useful for 
testing. Consider:

Western sans, serif and monospaced CFF:

 * https://github.com/adobe-fonts/source-sans-pro
 * https://github.com/adobe-fonts/source-serif-pro
 * https://github.com/adobe-fonts/source-code-pro

Pan CJK gothic and mincho (CID-based CFF):

 * https://github.com/adobe-fonts/source-han-sans
 * https://github.com/adobe-fonts/source-han-serif

Prototype CFF2 variable:

 * https://github.com/adobe-fonts/adobe-variable-font-prototype

When Adobe first developed CFF, they did convert their Type 1 library to CFF and did extensive round-trip 
testing for compatibility. In the end, Adobe decided not to risk releasing the converted fonts with the same 
names, but instead produced new CFF fonts with names including "Std" and "Pro" 
designations. The conversion code is available in the tool "tx", which is part of the Adobe Font 
Development Kit for OpenType. While I am not aware of any open source Type 1 fonts from Adobe, I'd suggest 
looking into converting some CFF fonts to Type 1 for testing.

 * http://www.adobe.com/devnet/opentype/afdko.html

-Dave


On 7/10/2017 6:09 AM, Werner LEMBERG wrote:

Finally fixed and pushed Type 1 seac.

Great, thanks!


One thing does bother me - the base characters of accented glyphs
(using seac), i.e. the stuff appearing around the fifth row, seem to
shift horizontally.  This is especially obvious with the accented
'i's which appear off center in Adobe mode.  Not sure if this is a
problem with the handling of left sidebearing, or some other metric,
I'm looking into it.

I suggest that you add calls to `FT_TRACE7' to trace seac stuff.  This
might be beneficial in general.


Once I've got that fixed up, I'll reorganize all the commits, add
changelogs, and update the clean branch.

Excellent.


Do tell me if you spot any other discrepancies in the new output.

I suggest that you compare output from, say, Adobe Acroread with your
new code; you won't get identical results but it should be similar
enough to catch gross errors.

Dave, what font or fonts do you recommend for testing?  AFAIK, Adobe
has converted virtually all of its Type1 fonts to CFF, and I think
that great care has been taken to reduce rendering differences to an
absolute minimum (if at all).


 Werner
.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Dave Arnold]

First, a clarification on terminology. I've seen "vertical stem" used to mean either a horizontal stroke that 
is moved vertically by hinting or a vertical stroke that is moved horizontally by hinting. Nikolaus is using the former 
here. I am biased to use the latter, because it matches the operator definitions of Type 1 and CFF fonts. For example, 
the operator "vstem" declares a hint for a vertical stroke that may be moved horizontally to "snap" 
to a pixel boundary. In other words, an "I" is a single vertical stem and a hyphen is a single horizontal 
stem.

In another email, Nikolaus talks about adjusting advance width as a function of 
hinting. In my opinion this is a poor trade-off. It is much harder for a layout 
engine to do its work if advance widths are a function of size. This also 
defeats the PostScript philosophy of scalability and device independence. Think 
about WYSIWYG if layout is not linearly scalable. I've seen some systems that 
try to account for the fractional position of a glyph origin by adjusting its 
advance width. In such a system, a glyph advance cannot be known until all 
previous glyphs in a line of text have been hinted and positioned. Layout and 
rendering must be run simultaneously.

The motivation for adjusting advance width like this is to improve interglyph spacing. I 
think it is much better to keep advance widths linearly scalable and avoid horizontal 
snapping of vertical stems — "light" hinting.

Thanks.

-Dave


On 7/10/2017 7:40 AM, Nikolaus Waxweiler wrote:

The gif you posted looks like the FreeType hinter is in "full" mode and
snaps stems both vertically *and* horizontally. The Adobe hinter snaps
just vertical stems, or "light". Not sure if the Type1 hinter knows what
"light" is.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.nongnu.org%2Fmailman%2Flistinfo%2Ffreetype-devel=02%7C01%7C%7Ce2b8aa93390d4c32d72808d4c7a1cc8d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636352945115817481=kVFn%2BvcvhoQybR3ZE1fAQA3gsjeBqOHZynTaA5Hlh%2Bk%3D=0
.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Nikolaus Waxweiler]

(background: "full" hinting changes the advance width of glyphs to
accomodate for spacing changes of horizontal stems)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Nikolaus Waxweiler]

The gif you posted looks like the FreeType hinter is in "full" mode and
snaps stems both vertically *and* horizontally. The Adobe hinter snaps
just vertical stems, or "light". Not sure if the Type1 hinter knows what
"light" is.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> Finally fixed and pushed Type 1 seac.

Great, thanks!

> One thing does bother me - the base characters of accented glyphs
> (using seac), i.e. the stuff appearing around the fifth row, seem to
> shift horizontally.  This is especially obvious with the accented
> 'i's which appear off center in Adobe mode.  Not sure if this is a
> problem with the handling of left sidebearing, or some other metric,
> I'm looking into it.

I suggest that you add calls to `FT_TRACE7' to trace seac stuff.  This
might be beneficial in general.

> Once I've got that fixed up, I'll reorganize all the commits, add
> changelogs, and update the clean branch.

Excellent.

> Do tell me if you spot any other discrepancies in the new output.

I suggest that you compare output from, say, Adobe Acroread with your
new code; you won't get identical results but it should be similar
enough to catch gross errors.

Dave, what font or fonts do you recommend for testing?  AFAIK, Adobe
has converted virtually all of its Type1 fonts to CFF, and I think
that great care has been taken to reduce rendering differences to an
absolute minimum (if at all).


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

Finally fixed and pushed Type 1 seac.

I ended up having to do the recursive call from inside instead of
using the callback, this is because following that code path resets
the outline, which is not desired in between loading base and accent
characters.

With this, Type 1 now works in new interpreter! Yet to test specific
edge cases. I've attached a little comparison gif.

One thing does bother me - the base characters of accented glyphs
(using seac), i.e. the stuff appearing around the fifth row, seem to
shift horizontally. This is especially obvious with the accented 'i's
which appear off center in Adobe mode. Not sure if this is a problem
with the handling of left sidebearing, or some other metric, I'm
looking into it.

Once I've got that fixed up, I'll reorganize all the commits, add
changelogs, and update the clean branch.

Do tell me if you spot any other discrepancies in the new output.


Ewald
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> Does the Adobe engine result in different advance widths as with
> using the old engine?

It shouldn't – if you ever encounter such a situation, there is a
problem that needs to be analyzed.

Theoretically, the only difference is in hinting.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

A quick question:
Does the Adobe engine result in different advance widths as with using
the old engine?

I am encountering problems as the `type1' driver initialises its
decoder with null for things like glyph slot and size when only
calculating advance widths, understandably as rendering is not needed.
However, the new engine needs these to be set before entering the
interpreter, and I would rather avoid creating a special case for this
scenario, instead of just using the old interpreter to calculate
advances. I assume that the new engine would not do anything different
for advances, but I want to be sure of this.

Ewald.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

>> I've pushed new updates to `wip'
>
> Thanks.  BTW, what shall happen with your other branches?  Are they
> now obsolete?

Sorry, that was unclear. I meant `ewaldhew-wip', which is for all
ongoing work. There's also `ewaldhew-cleaned', which is for
(hopefully) finalised stuff, with proper changelogs. I have no other
branches on savannah.

I have not found the need yet to do multiple topic branches, so my WIP
branch is just the one already up. That may change in the future if I
end up having to A/B test certain solutions.

>> I'm figuring if I could instead synthesize a dummy subfont record
>> for Type 1, copying over relevant values, ...
>
> This sounds sensible.

I'll proceed with this then. Actually, I've already done similarly for
`PS_Decoder' and `PS_Builder', which are basically wrappers over the
two kinds of decoders/builders. It seems to work fine and lets us keep
the old engine code unchanged.

> It depends on what you want to test...
>
> Ken Lunde has constructed some extreme CFF fonts for exactly such a
> purpose; have a look at
>
>   https://github.com/adobe-fonts
>
> and check repositories like `adobe-notdef' or `fdarray-test'.

Thanks, I'll check it out.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> I've pushed new updates to `wip'

Thanks.  BTW, what shall happen with your other branches?  Are they
now obsolete?

> I'm figuring if I could instead synthesize a dummy subfont record
> for Type 1, copying over relevant values, ...

This sounds sensible.

> ... but I am stumped for a good place to make that initialisation.
> (Doing it from the `type1' module seems a little strange...)

Don't worry too much.  From my experience with similar decisions, you
will get a good feeling later on to which place the affected code
should be eventually moved (in case you feel it necessary to do so).

> Also, if possible, could you suggest a good CFF font for testing
> changes?  Right now, I'm using one from Google Fonts but it looks
> wonky when hinted at small sizes, even on master branch.  Perhaps
> there is some font the appearance of which is already familiar to
> you (and hence any regressions are more apparent) ?

It depends on what you want to test...

Ken Lunde has constructed some extreme CFF fonts for exactly such a
purpose; have a look at

  https://github.com/adobe-fonts

and check repositories like `adobe-notdef' or `fdarray-test'.


Werner

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

> You can use http://git.ghostscript.com/?p=urw-core35-fonts.git to test
> things. URW++ provided Type1, CFF and TTF versions of the base
> Postscript fonts. The Type 1 fonts even had more than 256 glyphs per
> font last time I checked. The quality of the fonts is... ho-hum. The
> hinting (and by extension, the outlines) is off sometimes. But maybe
> it's enough for testing :)

Thanks, I'll give it a try.

Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Nikolaus Waxweiler]

> Also, if possible, could you suggest a good CFF font for testing
> changes? Right now, I'm using one from Google Fonts but it looks wonky
> when hinted at small sizes, even on master branch. Perhaps there is
> some font the appearance of which is already familiar to you (and
> hence any regressions are more apparent) ?

You can use http://git.ghostscript.com/?p=urw-core35-fonts.git to test
things. URW++ provided Type1, CFF and TTF versions of the base
Postscript fonts. The Type 1 fonts even had more than 256 glyphs per
font last time I checked. The quality of the fonts is... ho-hum. The
hinting (and by extension, the outlines) is off sometimes. But maybe
it's enough for testing :)

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

Hi,

I've pushed new updates to `wip'

The project compiles fine but there are still more things needed to
get the new interpreter to work in Type 1 mode. It seems to work fine
for old Type 1 and CFF engines, and new CFF, but it crashes in new
Type 1 mode due to missing fields in `PS_Decoder'.

Right now, in Type 1 mode it lacks the `current_subfont' field present
in CFF (and possibly font scaling/transform information - have not
confirmed this). As far as I can see, `current_subfont' is used to
access CFF private dict data. The straightforward but tedious fix is
adding a Type 1 mode to all the functions that access
`decoder->current_subfont' and have them go to `face->type1' where the
same data is stored for Type 1.

I'm figuring if I could instead synthesize a dummy subfont record for
Type 1, copying over relevant values, but I am stumped for a good
place to make that initialisation. (Doing it from the `type1' module
seems a little strange...)

Also, if possible, could you suggest a good CFF font for testing
changes? Right now, I'm using one from Google Fonts but it looks wonky
when hinted at small sizes, even on master branch. Perhaps there is
some font the appearance of which is already familiar to you (and
hence any regressions are more apparent) ?


Ewald

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> A heads up that I've pushed a new branch ewaldhew-wip to savannah
> for ongoing work.  I'll keep it based on the clean branch, and that
> on master.

OK, thanks.

> I had realised that the Type 1 and CFF builders contain practically
> the same data, [...]  and I now believe there is no problem as long
> as these are correctly merged.

Yeah :-)

> I also want to bring your attention to the notes regarding `seac'
> and `callothersubr''s duplicated operations. (in Todo)
> 
> For the former, following the other, implied `seac' in `endchar'
> that applies to Type 2 charstrings, i.e., retrieving charstring data
> and making the recursive call in the interpreter itself, will avoid
> the long chain of calls between the `psaux' and `type1' modules
> (which also uses a bunch of new objects - possible performance hit).
> I'm not sure if this is possible without first doing the objects
> change.

Please go for the easiest solution – the `seac' emulation in Type 2
charstrings is of limited use today because its restrictions are very
limiting (i.e., only glyph names used in `StandardEncoding').  In
other words, clean code is preferable to speed improvements.

> For the latter, those OtherSubrs are precisely the escaped
> operations in CFF charstrings.  I simply duplicated the code as I
> don't know if gotos are worth it.  However, they are in the same
> section of code so perhaps it won't be too confusing. (Comments will
> be added to clarify) What do you think?

Again, clean code is the preferred way to go I believe.  If necessary,
it should be not too difficult to optimize hot spots later on.


 Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Dave Arnold]

Hi Ewald,

I agree with your conclusion about number formats. Except for the 32000 (not 
32768) issue, Type 1 and CFF should be the same.

I'm sorry that I don't know enough about Type 1 fonts to answer your other questions. I 
had never heard of the "postscript stack" before you asked, and I don't have 
any test fonts for it. It appears that Type 1 interpreters outside of an actual 
PostScript environment can make simplifying assumptions.

-Dave


On 6/21/2017 7:56 PM, Ewald Hew wrote:


On the other hand, this means there should be no other issues with
number format between Type 1 or CFF ops, as long as the operands are
pushed correctly as above. Do correct me if I'm wrong.


Ewald.
.




___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Werner LEMBERG]

> P.S.  Is it OK if I rebase my clean git branch onto master every so
> often and do forced updates?

Yes.  This is your playground right now :-) I think this policy should
only be changed as soon as we are going to merge code into master – I
guess I'll then also commit stuff to your branch here and there, so
forced updates would prevent cooperation with other developers.

> Also, I'll delete the old `ewaldhew-refactor-cf2' branch as it's no
> longer needed.

OK.  Regarding my addition of ADD_INT32 and friends: To check whether
commit merging was done successfully it probably helps to use

  git diff --word-diff=color ...

also to get an alternative view on the diffs.


Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Ewald Hew]

Thanks for the reply!..

> I'm not familiar with the FreeType Type 1 code, but Adobe has a combined
> CFF+Type 1 interpreter where the "PostScript stack" is implemented by a
> simple array of 3 Fixed elements. I see a comment about a change to "skip
> the unique id check", if that helps.

..However, I am unable to locate this. A simple array makes sense, but
how was the limit of three decided? I don't have data for any fonts
that might call an unhandled othersubr, but it seems they might pass
in more arguments than that.

> The large number operator (255) expects small Type 1 values to be integers,
> converted to Fixed by << 16 (thus zero fraction). Large values are converted
> to Fixed by a subsequent div operator, and there is no shift when the
> numerator is pushed on the stack. CFF values are expected to already be
> Fixed, so there is no shift.

For CFF, small values (not 255 op) are stored in the stack as integers
and large ones interpreted as Fixed. Now for the old Type 1
interpreter, small values are stored as Fixed and large values are
stored as integers but are immediately converted to Fixed by the
subsequent `div'. However, `div' expects two Fixed arguments.

This means in handling Type 1, large values have a possible limit
issue when converted to Fixed by << 16. I'll need to extend `div' to
accept unscaled integers if `large_int' is set. My concern is that
`div' might be abused in Type 1 fonts, expecting an integer result for
use in indexing later. This would pass in the old interpreter but is
not allowed in the new one. Again, I have no reference to actual
fonts, so I don't know if this is a real problem.

On the other hand, this means there should be no other issues with
number format between Type 1 or CFF ops, as long as the operands are
pushed correctly as above. Do correct me if I'm wrong.


Ewald.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

[Dave Arnold]

Hi Ewald,

I'm not familiar with the FreeType Type 1 code, but Adobe has a combined CFF+Type 1 interpreter 
where the "PostScript stack" is implemented by a simple array of 3 Fixed elements. I see 
a comment about a change to "skip the unique id check", if that helps.

The large number operator (255) expects small Type 1 values to be integers, converted 
to Fixed by << 16 (thus zero fraction). Large values are converted to Fixed by 
a subsequent div operator, and there is no shift when the numerator is pushed on the 
stack. CFF values are expected to already be Fixed, so there is no shift.

-Dave


On 6/20/2017 4:26 AM, Ewald Hew wrote:

Hi,

I have now started merging Type 1 processing into the CF2
interpreter `cf2_interpT2CharString'. After considering the structure
of the interpreter I decided to put the control logic for shared
commands outside, i.e. inside the glyphpath functions, etc. instead.

Now, the differences in control flow and operand stack management
between the Type 1 and CF2 interpreter make this a non-trivial merge.

First off, the `callothersubr' operator is Type 1 only. So, in the old
interpreter, it simply leaves the results on top, 'pushing' them by
incrementing the pointer, or in the case of an unknown subr, waits for
the `pop' operator to do the same, that is, nothing is done and the
operands for `callothersubr' are left for subsequent `pop's. This is
not possible with `CF2_Stack', so we need some extra memory to hold
these ignored operands if they should be needed later.

What I understand from the spec is that there are two stacks, the
interpreter one and the PostScript one, but the latter has been
abbreviated in the old interpreter and not present in the new one. So
I could simply introduce another stack in which to store
`callothersubr' results in, implementing `pop' in the correct manner,
i.e. pop from one and push to the other. Is the cost of maintaining
another stack significant?

Also, is the different treatment of large numbers (charstring byte
255) between Type 1 and CFF a problem, control flow aside? Please tell
me if you know of any potential issues.

Regards,
Ewald

P.S.  Is it OK if I rebase my clean git branch onto master every so
often and do forced updates? Not exactly best practices but seems
easiest. Also, I'll delete the old `ewaldhew-refactor-cf2' branch as
it's no longer needed.

___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel
.



___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel