Re: [ft-devel] [GSoC] CID font support, and others

>> I'll use `format-patch' to extract the patches, then construct >> proper ChangeLog entries (based on your commit messages) and commit >> them to master. > > git cherry-pick SHA, vi ChangeLog, git commit -a, repeat... Yep. > Perhaps, Ewald is asking about specific plans to release his work.

Re: [ft-devel] [GSoC] CID font support, and others

On Tue, Aug 22, 2017 at 9:38 AM, Werner LEMBERG wrote: > >>> This mostly matters on 32-bit build without FT_LONG64. Forget about >>> it for now but don't lose the patch. Do you mind sharing it? >> >> I've pushed it to `ewaldhew-wip'. > > Thanks. > >> Also, I have questions regarding

Re: [ft-devel] [GSoC] CID font support, and others

> >> Werner, what are your plans for merging the code? > > I'll use `format-patch' to extract the patches, then construct proper > ChangeLog entries (based on your commit messages) and commit them to > master. git cherry-pick SHA, vi ChangeLog, git commit -a, repeat... Perhaps, Ewald is asking

Re: [ft-devel] [GSoC] CID font support, and others

>> Or any specific way you had in mind for us to consolidate all our >> work for submission (for archival purposes too)? Could also keep >> the working clean branch forever, or push a clone to github. > > Yes, keeping your branch makes sense – it should probably renamed so > that `GSoC 2017'

Re: [ft-devel] [GSoC] CID font support, and others

>> This mostly matters on 32-bit build without FT_LONG64. Forget about >> it for now but don't lose the patch. Do you mind sharing it? > > I've pushed it to `ewaldhew-wip'. Thanks. > Also, I have questions regarding final submission guidelines. I am > supposed to provide a stable link, I'm

Re: [ft-devel] [GSoC] CID font support, and others

> This mostly matters on 32-bit build without FT_LONG64. Forget about it for > now but don't lose the patch. Do you mind sharing it? I've pushed it to `ewaldhew-wip'. Also, I have questions regarding final submission guidelines. I am supposed to provide a stable link, I'm thinking of a commit

Re: [ft-devel] [GSoC] CID font support, and others

It should be pretty common when stem darkening is in effect. But it is not used otherwise. -Dave On 8/20/2017 10:31 PM, Werner LEMBERG wrote: It is interesting that `cf2_glyphpath_computeIntersection' never seems to get called... I think `normal' CFFs don't do that... Dave, do you have an

Re: [ft-devel] [GSoC] CID font support, and others

On Aug 21, 2017, at 00:23, Ewald Hew wrote: >> [...] >> This is just two things I noticed quickly. If you have time, you might >> find some speed gains this way. > > I tested after doing other similar changes, but any improvement was > within margin of error. It is

Re: [ft-devel] [GSoC] CID font support, and others

> It is interesting that `cf2_glyphpath_computeIntersection' never > seems to get called... I think `normal' CFFs don't do that... Dave, do you have an example font that actually needs this function? Werner ___ Freetype-devel mailing list

Re: [ft-devel] [GSoC] CID font support, and others

> [...] > This is just two things I noticed quickly. If you have time, you might > find some speed gains this way. I tested after doing other similar changes, but any improvement was within margin of error. It is interesting that `cf2_glyphpath_computeIntersection' never seems to get called...

Re: [ft-devel] [GSoC] CID font support, and others

Hi Werner, You are correct that CoolType does not have the improvement that the initial hintmap was designed for. It also does not have some of the heuristics that improve rendering of complex CJK glyphs. On the other hand, CoolType has more code devoted to rendering bilevel bitmaps. (In the

Re: [ft-devel] [GSoC] CID font support, and others

Ewald, Here http://git.savannah.gnu.org/cgit/freetype/freetype2.git/tree/src/psaux/pshints.c?h=ewaldhew-wip#n1251 FT_DivFix is followed by 2 FT_MulFix's. It could be faster to do combine them into two FT_MulDiv's. Here

Re: [ft-devel] [GSoC] CID font support, and others

> Are you benchmarking a 32-bit build? How unfashionable of you :) The system-provided version is 32-bit (not sure why??). After properly linking I have a 64-bit build, and FT_DivFix does not seem to be a problem any more :-) > https://savannah.nongnu.org/bugs/?43248 > Now I have that the

Re: [ft-devel] [GSoC] CID font support, and others

> Ewald, are you using freetype2-demos/bin/* wrapper scripts? They > supposed to LD_PRELOAD from the neighboring freetype2/objs/.libs > folder. Even standard (not devel) build works for me like this. Hm... when I used those, callgrind seemed to be unable to capture the process, grabbing

Re: [ft-devel] [GSoC] CID font support, and others

> By the way, there is this outstanding bug > https://savannah.nongnu.org/bugs/?43248. Perhaps you can profile > the engine and post the details. Uh, oh, he is doing this partly for this very bug report – you recommended to him to have a look :-) Werner

Re: [ft-devel] [GSoC] CID font support, and others

> git clean -fdx > git reset --hard # or manually check for missing files/interfering changes > make devel > make Thanks, it works now. I've managed to reproduce the slow load times, turns out I had forgot to compile CFF old engine and it was using the new engine regardless(whoops!).

Re: [ft-devel] [GSoC] CID font support, and others

>> In fact, it seems like the demos >> are linking to my system-provided libfreetype instead of the git >> devel one, hence no debug information. I'm trying to fix that right >> now. > > Are you doing a `developer's build' (i.e., `make devel; make' in > `freetype2', then a simple `make' in

Re: [ft-devel] [GSoC] CID font support, and others

>> git clean -fdx (Use with caution! Check before with `git clean -ndx) >> make devel >> make > > I get: > config.mk:25: builds/unix/unix-def.mk: No such file or directory > config.mk:26: builds/unix/unix-cc.mk: No such file or directory > make: execvp: ./include/freetype/freetype.h:

Re: [ft-devel] [GSoC] CID font support, and others

> git clean -fdx (Use with caution! Check before with `git clean -ndx) > make devel > make I get: config.mk:25: builds/unix/unix-def.mk: No such file or directory config.mk:26: builds/unix/unix-cc.mk: No such file or directory make: execvp: ./include/freetype/freetype.h: Permission

Re: [ft-devel] [GSoC] CID font support, and others

>> Are you doing a `developer's build' (i.e., `make devel; make' in >> `freetype2', then a simple `make' in `freetype2-demos')? This >> should create statically linked binaries quite easily. > > Strange... make insists that there is nothing to be done for > `devel'. What am I missing? git

Re: [ft-devel] [GSoC] CID font support, and others

> Are you doing a `developer's build' (i.e., `make devel; make' in > `freetype2', then a simple `make' in `freetype2-demos')? This should > create statically linked binaries quite easily. Strange... make insists that there is nothing to be done for `devel'. What am I missing? Ewald

Re: [ft-devel] [GSoC] CID font support, and others

>> Ewald, have you already done some benchmarks? > > I finally got the freetype2-demos to work with callgrind, but many > of the calls have no debug label. In fact, it seems like the demos > are linking to my system-provided libfreetype instead of the git > devel one, hence no debug

Re: [ft-devel] [GSoC] CID font support, and others

Thanks Dave for the helpful explanation! >> I suppose you could disable the use of the initial hintmap for Type 1 >> charstrings only. > > If I understand correctly, this is what Ewald started with, and he got > bad results... No, it was always enabled, but built wrongly as we don't have all the

Re: [ft-devel] [GSoC] CID font support, and others

Hello Dave, thanks for your detailed response. > The initial hintmap feature is relatively new in Adobe's CFF > rasterizers. It does not exist in CoolType (the rasterizer used in > Acrobat). CoolType uses an interpreter that handles either Type 1 > or CFF in one pass. But because it does

Re: [ft-devel] [GSoC] CID font support, and others

>> OK, I'll be finding a way to add this in with minimal clutter to >> the code. I'm thinking to add an extra check to the top to skip >> stuff other than stem hints first time round, then rewinding on >> `endchar'. > > Done. Pushed along with some other minor changes. > > I've checked this with

Re: [ft-devel] [GSoC] CID font support, and others

> OK, I'll be finding a way to add this in with minimal clutter to the > code. I'm thinking to add an extra check to the top to skip stuff > other than stem hints first time round, then rewinding on `endchar'. Done. Pushed along with some other minor changes. I've checked this with all the known

Re: [ft-devel] [GSoC] CID font support, and others

>> Sorry, I'm not sure how I should go about this. I went with >> exporting PDF from LibreOffice, but when I opened that in Acroread I >> get LCD rendering (see attached). > > Well, yes. > > Monochrome? Please explain. I think there no longer exists an > environment where Acroread would return

Re: [ft-devel] [GSoC] CID font support, and others

> \documentclass{article} > > \input{binhex} Oops, outdated version. Here's a better one for the compact output. Werner \documentclass{article} \usepackage{fontspec} \setmainfont{Linux Libertine O} \usepackage{multido} \setlength{\parindent}{0pt} \begin{document}

Re: [ft-devel] [GSoC] CID font support, and others

> Our complication is that we must be placing outline points alongside > reading the hints, and adjusting the former accordingly. OK, makes sense. So it seems boiling down to the question how to optimally hint Type1, right? >> . Test with Acroread whether Type1 fonts and its CFF conversions >>

Re: [ft-devel] [GSoC] CID font support, and others

> Until then, I suggest to do some more research. Looking around in the > web for Type1->CFF converters I always read that hint conversion is > `trivial' [not sure whether those guys just report hearsay or whether > they have actually tried and tested it]. I wouldn't call it trivial, but it's

Re: [ft-devel] [GSoC] CID font support, and others

>>> The only other solution that comes to mind is doing an extra pass >>> just to build the initial hintmap, after which hint moves should >>> presumably work right. >> >> I like your first suggestion better. > > I would prefer changing the logic too, but that doesn't seem > feasible. Look at

Re: [ft-devel] [GSoC] CID font support, and others

>> The only other solution that comes to mind is doing an extra pass >> just to build the initial hintmap, after which hint moves should >> presumably work right. > > I like your first suggestion better. I would prefer changing the logic too, but that doesn't seem feasible. Look at this output

Re: [ft-devel] [GSoC] CID font support, and others

> Please give an exact recipe how you configure and compile FreeType (on > what platform?), and how you call valgrind (which version, BTW?) – > I'll try to reproduce. I'm using Debian 8.9 (jessie). I've always compiled FreeType with the provided makefile, which calls gcc with -g and -O2 for

Re: [ft-devel] [GSoC] CID font support, and others

>> What did you exactly do? > > I just followed the instructions in callgrind manual > (http://valgrind.org/docs/manual/cl-manual.html#cl-manual.basics). I > confirmed that FreeType was compiling with -g and used kcachegrind > as the visualiser. Please give an exact recipe how you configure and

Re: [ft-devel] [GSoC] CID font support, and others

[Dave, please comment!] > Refer to diff.txt. Nice! > Each occurence of "Hints: ..." represents one hint change (with > OtherSubr 3 or hintmask respectively). Flags are, p=Pair, g=Ghost, > t=Top, b=Bottom, L=Locked, S=Synthetic. Maybe it makes sense to mention the abbreviations once in the

Re: [ft-devel] [GSoC] CID font support, and others

>> I think I've isolated the problem with hinting. Suffice to say the >> hinter works on the premise that all hints are known at the start. >> This is generally not true for Type 1 fonts. Perhaps it is possible >> to change the logic to remove this condition. > > Hmm. Please elaborate and give

Re: [ft-devel] [GSoC] CID font support, and others

> I think I've isolated the problem with hinting. Suffice to say the > hinter works on the premise that all hints are known at the start. > This is generally not true for Type 1 fonts. Perhaps it is possible > to change the logic to remove this condition. Hmm. Please elaborate and give an

Re: [ft-devel] [GSoC] CID font support, and others

> I suggest that you add tracing messages. For example, the attached > excerpt from a log file shows what the auto-hinter emits for glyph > index 2 of the font `c059013l.pfb' (URW Century Schoolbook L Roman > version 1.06). I called > > FT2_DEBUG=any:7 ftview 20 c059013l.pfb &> c059013l.log >

Re: [ft-devel] [GSoC] CID font support, and others

> You might (or might not?) have noticed, I've pushed all changes into > `ewaldhew-cleaned' a few days ago. I noticed, thanks, but I'm still on vacation, so it will take some time until I can comment on more details. > I've been comparing the charstrings and hinter movements, but the > lack of