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

> 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

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

> 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 (

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

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,

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

> 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

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

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

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

> 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

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

> 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'

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

>> 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

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

>> 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

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

> 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

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

> 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

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

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

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

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

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

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

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

(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

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

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

> 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

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

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

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

> 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

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

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

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

>> 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

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

> 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

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

> 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

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

> 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

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

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'.

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

> 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

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

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

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

> 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

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

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.

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

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