Re: [ft-devel] Markdown generated with docmaker, and website

[Ewald Hew]

Hi,

Looks great! Just a minor suggestion, I think it might be good to have
the index page get less columns as the page width shrinks, it gets
pretty hard to read when the aspect ratio is tall.

Ewald

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

Re: [ft-devel] Contribution to freetype

[Ewald Hew]

Hi Parth,

> I am unable to figure out the working of `FT_Face_InitFunc` in the `ftdrv.h`
> file.
> particularly, how does the call to `init_face` function invokes the
> particular font format's driver.
> Please help.

I suggest you read the article here
, which
goes into some detail about how interfaces are being implemented in
FreeType.

Basically, `FT_Face_InitFunc' is a function pointer type (with its
signature), through which the driver-specific implementation of
`init_face' can be set, per module. Look up the `FT_DEFINE_DRIVER'
macro and where it's being used.

Ewald

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

Re: [ft-devel] New FreeType release within a week

[Ewald Hew]

>> [...] I went with a different approach, to switch off hinting only
>> if the hintmap is full.  Compare attached patches.
>
> Honestly, I can't decide which is better.  Please proceed as you
> believe is best.

In the interest of time, I've commited the original suggestion for
now, as I feel that my alternative solution is a bit of a hack as it
is; I have to test other fonts and decide if it's better to keep
hinting on, and devise a better way of ignoring the hintmask than what
I've provided above.

> And thanks for working on this!

It's a pleasure :)

Ewald

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

Re: [ft-devel] New FreeType release within a week

[Ewald Hew]

>> I looked at the example that Ewald gave, ztm-Reg.pfb gid 479
>> 'shade'.  While the [hv]stem operators are used 344 times in this
>> charstring, the hints are not all unique.  There are just 10 unique
>> hstems and 10 unique vstems.  When converted to CFF, this font would
>> therefore declare just 20 hints, easily within the limit.
>
> This is a very good point.  It seems that T1 support could be improved
> by adding one additional step, namely to make hints unique.  However,
> such an extra step costs time.  If an arbitrary number of hints is
> allowed (using dynamic allocation) – which we eventually have to
> support anyway – this extra step might not be necessary.

Actually, the hintmap already does this - overlapping hints are not
inserted. So I went with a different approach, to switch off hinting
only if the hintmap is full. Compare attached patches.

With this, none of the fonts across TeXLive fail (as in fall back to
non-hinted). However, I wonder if the hinted output of such glyphs are
actually better. See attached pictures.

`stems.png' is the result of turning off hinting since 344 hints is
more than the allowed 96 (I'm not sure why the outline shifts a
little).

`hintmap.png' does not, since there are only 20 hints in the initial
hintmap. However, it introduces some jagged edges on the output due to
the alignment. Likewise with the "4111 hints" glyph, hinted output
sort of stretches the uniform grid of circles outwards on the ends.
Although, these may be isolated cases...

Ewald
From 2959d7315824012416b22fa76f1b5aa112cdffb8 Mon Sep 17 00:00:00 2001
From: Ewald Hew <ewald...@gmail.com>
Date: Wed, 3 Jan 2018 10:09:45 +0800
Subject: [PATCH] off hinting if hintmap full

---
 src/psaux/pshints.c | 39 +++
 1 file changed, 23 insertions(+), 16 deletions(-)

diff --git a/src/psaux/pshints.c b/src/psaux/pshints.c
index b53ca6745..3d77b0a5d 100644
--- a/src/psaux/pshints.c
+++ b/src/psaux/pshints.c
@@ -760,6 +760,7 @@
   if ( iDst >= CF2_MAX_HINT_EDGES )
   {
 FT_TRACE4(( "cf2_hintmap_insertHint: too many hintmaps\n" ));
+hintmap->hinted = FALSE;
 return;
   }
 
@@ -836,7 +837,7 @@
  TRUE );
 }
 
-if ( !cf2_hintmask_isValid( hintMask ) )
+if ( !cf2_hintmask_isValid( hintMask ) && !font->isT1 )
 {
   /* without a hint mask, assume all hints are active */
   cf2_hintmask_setAll( hintMask,
@@ -858,7 +859,7 @@
 bitCount = cf2_arrstack_size( hStemHintArray );
 
 /* Defense-in-depth.  Should never return here. */
-if ( bitCount > hintMask->bitCount )
+if ( bitCount > hintMask->bitCount && !font->isT1 )
   return;
 
 /* synthetic embox hints get highest priority */
@@ -884,7 +885,7 @@
 /* priority)  */
 for ( i = 0, maskByte = 0x80; i < bitCount; i++ )
 {
-  if ( maskByte & *maskPtr )
+  if ( font->isT1 || ( maskByte & *maskPtr ) )
   {
 /* expand StemHint into two `CF2_Hint' elements */
 CF2_HintRec  bottomHintEdge, topHintEdge;
@@ -918,14 +919,17 @@
 }
   }
 
-  if ( ( i & 7 ) == 7 )
+  if ( !font->isT1 )
   {
-/* move to next mask byte */
-maskPtr++;
-maskByte = 0x80;
+if ( ( i & 7 ) == 7 )
+{
+  /* move to next mask byte */
+  maskPtr++;
+  maskByte = 0x80;
+}
+else
+  maskByte >>= 1;
   }
-  else
-maskByte >>= 1;
 }
 
 /* initial hint map includes only captured hints plus maybe one at 0 */
@@ -985,7 +989,7 @@
 
   for ( i = 0, maskByte = 0x80; i < bitCount; i++ )
   {
-if ( maskByte & *maskPtr )
+if ( font->isT1 || ( maskByte & *maskPtr ) )
 {
   CF2_HintRec  bottomHintEdge, topHintEdge;
 
@@ -1008,14 +1012,17 @@
   cf2_hintmap_insertHint( hintmap, ,  );
 }
 
-if ( ( i & 7 ) == 7 )
+if ( !font->isT1 )
 {
-  /* move to next mask byte */
-  maskPtr++;
-  maskByte = 0x80;
+  if ( ( i & 7 ) == 7 )
+  {
+/* move to next mask byte */
+maskPtr++;
+maskByte = 0x80;
+  }
+  else
+    maskByte >>= 1;
 }
-else
-  maskByte >>= 1;
   }
 }
 
-- 
2.11.0

From 2b20d1e641a9b036d04d0e9239f2dc8ea9ede377 Mon Sep 17 00:00:00 2001
From: Ewald Hew <ewald...@gmail.com>
Date: Wed, 3 Jan 2018 10:32:53 +0800
Subject: [PATCH] off hinting if too many stems

---
 src/psaux/pshints.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/src/psaux/pshints.c b/src/psaux/pshints.c
index b53ca6745..31cca146d 100644
--- a/sr

Re: [ft-devel] New FreeType release within a week

[Ewald Hew]

> I'm wondering, how about leaving the CFF limit as is and apply it to Type1,
> too, and just turn off hinting for that glyph? Not entirely correct, but an
> easy way out when the hinting obviously went wrong.

Actually, since the FreeType hinter handles it fine, how about
returning a specific error code when this happens and fall back to the
old engine, if it is available? Otherwise, perhaps the autohinter?

Ewald

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

Re: [ft-devel] New FreeType release within a week

[Ewald Hew]

> Yes, sounds sensible, thanks.  Could you do a sweep over all Type 1
> fonts from TeXLive just to be sure?  I guess this is the most
> important repository of PFB files that is still in use.

After increasing the limit to 360, out of 6802 fonts tested in
TeXLive, 53 fonts still failed, down from 731.

The largest number of hints is 4111 (!). Attached is the output for all
fonts still with rejected glyphs.

It's definitely not practical to increase the limit so much; I'm
thinking that this is good enough for now. I'll work on getting it
fixed up in the way as mentioned previously.

Ewald
ftbench results for font `./public/arev/ArevSans-BoldOblique.pfb'
  index 665 too many stems, had 554
ftbench results for font `./public/arev/ArevSans-Roman.pfb'
  index 669 too many stems, had 554
ftbench results for font `./public/arev/ArevSans-Bold.pfb'
  index 666 too many stems, had 554
ftbench results for font `./public/arev/ArevSans-Oblique.pfb'
  index 667 too many stems, had 554
ftbench results for font `./public/fonts-tlwg/laksaman.pfb'
  index 373 too many stems, had 1579
ftbench results for font `./public/fonts-tlwg/laksaman_bi.pfb'
  index 373 too many stems, had 1579
ftbench results for font `./public/fonts-tlwg/laksaman_b.pfb'
  index 373 too many stems, had 1579
ftbench results for font `./public/fonts-tlwg/laksaman_i.pfb'
  index 373 too many stems, had 1579
ftbench results for font `./public/stix/STIXGeneral-Regular.pfb'
  index 1475 too many stems, had 4111
  index 1476 too many stems, had 1456
  index 1477 too many stems, had 2580
ftbench results for font `./public/skaknew/SkakNew-Diagram.pfb'
  index 20 too many stems, had 399
ftbench results for font `./public/libertinust1math/LibertinusT1Math.pfb'
  index 3168 too many stems, had 885
  index 3185 too many stems, had 811
  index 3278 too many stems, had 546
  index 3285 too many stems, had 558
ftbench results for font `./public/nimbus15/zhv-Bol.pfb'
  index 479 too many stems, had 370
ftbench results for font `./public/nimbus15/zhv-RegIta.pfb'
  index 479 too many stems, had 370
ftbench results for font `./public/nimbus15/zco-Oblique.pfb'
  index 479 too many stems, had 401
ftbench results for font `./public/nimbus15/zco-Regular.pfb'
  index 726 too many stems, had 401
ftbench results for font `./public/nimbus15/zhv-BolIta.pfb'
  index 479 too many stems, had 370
ftbench results for font `./public/nimbus15/zhv-Reg.pfb'
  index 479 too many stems, had 370
ftbench results for font `./public/staves/icelandic.pfb'
  index 56 too many stems, had 449
  index 57 too many stems, had 459
ftbench results for font `./public/ebgaramond/EBGaramondInitials.pfb'
  index 1 too many stems, had 1121
  index 2 too many stems, had 695
  index 3 too many stems, had 635
  index 4 too many stems, had 742
  index 5 too many stems, had 486
  index 6 too many stems, had 1196
  index 7 too many stems, had 523
  index 8 too many stems, had 746
  index 9 too many stems, had 624
ftbench results for font `./public/ebgaramond/EBGaramond12-Regular.pfb'
  index 3019 too many stems, had 1058
ftbench results for font `./public/initials/Kramer.pfb'
  index 20 too many stems, had 408
  index 31 too many stems, had 412
ftbench results for font `./public/cbfonts/gomu0900.pfb'
  index 5 too many stems, had 374
  index 11 too many stems, had 451
ftbench results for font `./public/cbfonts/goxn0700.pfb'
  index 11 too many stems, had 473
ftbench results for font `./public/cbfonts/gomn1095.pfb'
  index 10 too many stems, had 363
  index 11 too many stems, had 487
ftbench results for font `./public/cbfonts/gomu1095.pfb'
  index 11 too many stems, had 463
ftbench results for font `./public/cbfonts/goxu0700.pfb'
  index 11 too many stems, had 473
ftbench results for font `./public/cbfonts/goxu1440.pfb'
  index 4 too many stems, had 417
ftbench results for font `./public/cbfonts/gomc0800.pfb'
  index 4 too many stems, had 382
ftbench results for font `./public/cbfonts/goxu0800.pfb'
  index 10 too many stems, had 406
  index 11 too many stems, had 528
ftbench results for font `./public/cbfonts/gomc0900.pfb'
  index 4 too many stems, had 365
  index 5 too many stems, had 374
  index 11 too many stems, had 451
  index 156 too many stems, had 429
  index 157 too many stems, had 429
  index 158 too many stems, had 429
  index 164 too many stems, had 429
  index 165 too many stems, had 429
  index 166 too many stems, had 429
  index 167 too many stems, had 429
  index 172 too many stems, had 429
  index 173 too many stems, had 429
  index 174 too many stems, had 429
  index 175 too many stems, had 429
  index 248 too many stems, had 429
ftbench results for font `./public/cbfonts/goxn1095.pfb'
  index 11 too many stems, had 427
ftbench results for font `./public/cbfonts/goxu0900.pfb'
  index 11 too many stems, had 503
ftbench results for font `./public/cbfonts/gomn0900.pfb'
  index 5 too many stems, had 374
  index 11 too many stems, had 451
ftbench results for font `./public/cbfonts/gomc0700.pfb'
  index 

Re: [ft-devel] New FreeType release within a week

[Ewald Hew]

> . Ewald, I suggest that we simply increase the allowed number of hints
>   for Type 1 fonts – we can still fix this later if really needed.

The allowed number of hints is set by the value `CF2_MAX_HINTS'
defined in `pshints.h', this value determines the amount of memory
allocated for the hintmap records and hintmask too. So we can increase
the limit to something higher but really only as a temporary fix, I
think. Does 360 sound good (since the one had 344 hints)?

As for a long-term fix, fortunately, hintmasks are not used in Type 1,
so we can focus on the hint records. These could use an ArrStack
instead, removing the arbitrary limit on Type 1 fonts, while adding
checks to enforce the limit for CFF.

Ewald

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

[ft-devel] Issue with CFF implementation limits

[Ewald Hew]

Hi all,

I've found an issue with certain Type 1 glyphs being rejected by the
new Adobe engine for having too many stems. According to the
specification, CFF charstrings can have at most 96 stem hints (cf.
https://www.microsoft.com/typography/otspec/cff2charstr.htm#appendix_Limits),
but this limitation is not in place for Type 1 charstrings.

I've attached a really extreme case of this, from `ztm-Reg.pfb'
(https://ctan.org/tex-archive/fonts/nimbus15/type1). Glyph 479 has a
whopping 344 hints!

A simple fix may be to remove the limit for Type 1 fonts, but I don't
know if this is good practice or wouldn't cause other problems in the
hinter logic. Any input or suggestions are greatly appreciated!


Ewald


debug.log
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] segfault in psaux/psft.c:98

[Ewald Hew]

Fix is up.

The `glyph_width' field is only used, and valid, when it's a CFF font,
but I'd missed out the all-important check when changing this to a
write-back for the prior patch m(._. ;))m

Ewald

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

Re: [ft-devel] segfault in psaux/psft.c:98

[Ewald Hew]

> commit b9bd2d14e2836122028b4f41eee937fc31e6b93c AD)

Woops, yes. Slipped my mind.

Working on it now, fix will be up soon.

Ewald

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

Re: [ft-devel] various Type 1 -> CFF issues

[Ewald Hew]

>>> * Make the old type 1 driver optional.  The file `ftt1drv.h' is
>>>   talking about a `T1_CONFIG_OPTION_OLD_ENGINE' configuration
>>>   macro, however, this isn't implemented yet.

>> I could extract the advance width processing from the old
>> interpreter into a separate function, which gets always compiled in,
>> with the rest switched by the macro.
>
> Please proceed!  I think it would be good to isolate the old Type1
> engine as much as possible.

>>> * Implement the `hinting-engine' property for the `type1' module.

All done. Attached patches that separate the advance width function,
adds the config macro, and adds the property service for `type1' and
`cid'.

I did a quick hack in `ftview' for testing, seems to work fine but
needs cleaning up before I can provide the patch for the demos to
support hinting engine cycling for Type 1 fonts.

Ewald


0001-Extract-width-parsing-from-Type-1-parser.patch
Description: Binary data


0002-Add-T1_CONFIG_OPTION_OLD_ENGINE-configuration-option.patch
Description: Binary data


0003-type1-cid-Add-hinting-engine-switch.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] various Type 1 -> CFF issues

[Ewald Hew]

> In file included from /home/apodtele/freetype2/src/psaux/psaux.c:35:0:
> /home/apodtele/freetype2/src/psaux/pshints.c: In function ‘cf2_hintmap_dump’:
> /home/apodtele/freetype2/src/psaux/pshints.c:312:17: warning: unused
> variable ‘hint’ [-Wunused-variable]
>CF2_Hint  hint = >edge[i];
>  ^~~~

I've just pushed the fix.

Ewald

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

Re: [ft-devel] various Type 1 -> CFF issues

[Ewald Hew]

> * Make the old type 1 driver optional.  The file `ftt1drv.h' is
>   talking about a `T1_CONFIG_OPTION_OLD_ENGINE' configuration macro,
>   however, this isn't implemented yet.

I had actually implemented it, but did not commit later on, c.f.
  http://lists.nongnu.org/archive/html/freetype-devel/2017-07/msg00010.html

I had decided that since the new engine incurs so much overhead it
would not be good to use it for scanning advance widths. The old
routine rightly does not initialise any of the glyph rendering
objects, but it would take considerable changes to the new engine to
do the same, which I felt was not worth it.

I could extract the advance width processing from the old interpreter
into a separate function, which gets always compiled in, with the rest
switched by the macro.

> * Implement the `hinting-engine' property for the `type1' module.
>
> * `FT_PARAM_TAG_RANDOM_SEED' is defined twice (in `ftt1drv.h' and
>   `ftcffdrv.h').  I think this should be removed – all properties for
>   the new Type 1 engine should be in `ftcffdrv.h' only, and it's not
>   worth to add random seed control to the old engine.  Do you agree?

I think so too - this is something I overlooked when copying the file
over from `ftcffdrv.h'. I had renamed the class to PS_Driver,
which all three drivers are now using.

The only property there is `hinting_engine'. I differentiated
`FT_T1_HINTING_' from `FT_CFF_HINTING_', but maybe we can just use
`FT_PS_HINTING_' for both.

Ewald

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

Re: [ft-devel] merged CFF and Type1 hinting code now in master

[Ewald Hew]

> Not sure if it's caused by the merge, but it gives a warning with gcc 7.2.0:
>
> ---
> In file included from
> /home/nsivov/devel/freetype/freetype2/src/psaux/psaux.c:35:0:
> /home/nsivov/devel/freetype/freetype2/src/psaux/pshints.c: In function
> ‘cf2_hintmap_dump’:
> /home/nsivov/devel/freetype/freetype2/src/psaux/pshints.c:312:17: warning:
> unused variable ‘hint’ [-Wunused-variable]
>CF2_Hint  hint = >edge[i];
>  ^~~~
> ---

Yes, it is caused by the tracing procedure I added to debug the
initial hintmap issue. All this does is use FT_TRACE to print out some
tables, so if debug mode isn't turned on, the `hint' variable's not
being used.

The following patch should fix it:

>From ca8de3f50731167a8a096a5a8afb7b171fa3f640 Mon Sep 17 00:00:00 2001
From: Ewald Hew <ewald...@gmail.com>
Date: Tue, 26 Sep 2017 00:16:26 +0800
Subject: [PATCH] Fix compiler warning.

---
 src/psaux/pshints.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/psaux/pshints.c b/src/psaux/pshints.c
index cf40bc0..c8ad4e0 100644
--- a/src/psaux/pshints.c
+++ b/src/psaux/pshints.c
@@ -302,6 +302,7 @@
   static void
   cf2_hintmap_dump( CF2_HintMap  hintmap )
   {
+#ifdef FT_DEBUG_LEVEL_TRACE
 CF2_UInt  i;


@@ -321,6 +322,9 @@
   ( cf2_hint_isLocked( hint ) ? "L" : ""),
   ( cf2_hint_isSynthetic( hint ) ? "S" : "" ) ));
 }
+#else
+FT_UNUSED( hintmap );
+#endif
   }


-- 
2.1.4

Ewald
From ca8de3f50731167a8a096a5a8afb7b171fa3f640 Mon Sep 17 00:00:00 2001
From: Ewald Hew <ewald...@gmail.com>
Date: Tue, 26 Sep 2017 00:16:26 +0800
Subject: [PATCH] Fix compiler warning.

---
 src/psaux/pshints.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/psaux/pshints.c b/src/psaux/pshints.c
index cf40bc0..c8ad4e0 100644
--- a/src/psaux/pshints.c
+++ b/src/psaux/pshints.c
@@ -302,6 +302,7 @@
   static void
   cf2_hintmap_dump( CF2_HintMap  hintmap )
   {
+#ifdef FT_DEBUG_LEVEL_TRACE
 CF2_UInt  i;
 
 
@@ -321,6 +322,9 @@
   ( cf2_hint_isLocked( hint ) ? "L" : ""),
   ( cf2_hint_isSynthetic( hint ) ? "S" : "" ) ));
 }
+#else
+FT_UNUSED( hintmap );
+#endif
   }
 
 
-- 
2.1.4

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

Re: [ft-devel] freetype-web: New documentation regarding interfaces and services.

[Ewald Hew]

> (I converted many things already: https://github.com/madig/freetype-web -- I
> just didn't have the time to follow this up. The big missing part would be
> integrating the design of FreeType.org)

Ah, I see, I missed that. Thanks :)

Seems like the task is mostly done, then. I imagine we could have
sources in markdown and make page template + site listing description
files, then have a python script to generate the HTML pages for
publishing.
Thoughts?

Ewald

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

[ft-devel] freetype-web: New documentation regarding interfaces and services.

[Ewald Hew]

Hi,

I've drafted up an addition to the `FreeType design' segment which
covers interfaces in FreeType. See two attached patches.

Still to do is adding instructions for adding PIC support to the
service guide. Tell me if you feel there is too little or too much
detail, or something about the format/layout.

I recall a discussion quite some time back about moving the guides to
Markdown format, but converting existing sources was an issue. I am
looking to take up the task unless there are other reasons against it.

Ewald


0001-design-Add-new-page.patch
Description: Binary data


0002-design-Add-service-guide.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel

[ft-devel] [GSoC-2017] Adding support for Type 1 fonts to Adobe CFF Engine

[Ewald Hew]

Hi all,

I am Ewald Hew, and I have been involved in FreeType development as a
participant of GSoC.
Over the summer, I have been implementing support for Type 1 fonts in the
CFF engine that Adobe has contributed, and have achieved improvement in
hinted
output for Type 1 fonts similar to that for CFF fonts.

Working branch:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/log/?h=GSoC-2017-ewaldhew-wip
Full diff:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=423d7cf=a650c95^

Following is an overview of changes made and challenges faced:

1. Moving the Adobe engine from `cff' to `psaux' modules. (a650c95~2cef133
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=2cef133=a650c95^>
)
- This was important to move the engine from a CFF-only component to an
inter-module service.
- I was relatively new to the codebase then, unfamiliar with the pseudo-OOP
in C, and faced initial difficulty following code paths and finding
separation points between the engine and module.
- I succeeded through a mix of cross-referencing, discussion, and checking
compiler errors.

2. Make Type 1 and CID glyph loading use this new service. (d6983de~a4b0acf
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=a4b0acf=2cef133>
,
46a062c~aedfc70
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=aedfc70=46a062c^>
)
- The new engine had to accept objects for glyph loading whether Type 1 or
CFF,
which had subtly different structures. The modules had to access the new
service, a single API, in the same way.
- A significant challenge was implementing "polymorphism" for the loading
objects in the new engine, while keeping old APIs the same if possible.
- I decided to use wrapper objects that simply copied over relevant fields,
thus keeping the Type 1 vs. CFF stuff outside the interpreter.

3. Extending the interpreter to understand Type 1 charstrings.
(7927aff~150c989
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=150c989=a4b0acf>
)
- Now that Type 1 data would be routed through the new engine, it had to
accept
Type 1 charstrings, which have different rules and operations that were
removed in the Type 2 specification.
- This step required a lot of referencing the spec, and adapting operations
to
match the engine's underlying logic to achieve the correct results.
- Ensuring edge cases were properly covered was a challenge, but the
detailed
tracing output and simple but functional `demos' test suite helped a lot.

4. Testing, debugging, cleaning up. (57b7f9f~423d7cf
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/diff/?id=423d7cf=aedfc70>
)
- The final step was ensuring that everything works and confirming the
rendering improvements.
- A particularly bad hinting issue was found, caused by a conflict between
hint
declarations in Type 1 and the single-pass hinting engine.
- It was decided to add an extra pass for best hinting results, rather than
to
disable the function and get not as good hinting.
- I also did some other minor fixes to code and comments.


I also went on to investigate an outstanding issue regarding performance of
the
new engine (bug #43248). I achieved some initial success (commit c48e55b
<http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?h=GSoC-2017-ewaldhew-wip=c48e55b738b5a3cc57f20eb7b949fcfec5ca9dd4>)
but
I think that further improvement is possible. This will be a continuing
effort
and I do intend to continue contributing to the FreeType project.

I wish to thank my mentors and the rest of the community who participated
in
discussions and helped me refine my solutions and making GSoC with FreeType
a
truly engaging and great learning experience.

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

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

[Ewald Hew]

> 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 range on
master on cgit, since Savannah has no "merge request" functionality.
Werner, what are your plans for merging the code? 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.

Ewald

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

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

[Ewald Hew]

> [...]
> 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...

Ewald

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

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

[Ewald Hew]

> 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 glyphpath procedures take a bulk of the time.
> What's interesting is the hinting functions get called from these,
> regardless of the load flags, and probably explains why it's roughly
> the same hinted or not. This seems wrong IMO, as we should be ignoring
> hints accordingly, but the call graph shows `cf2_hintmap_build',
> `cf2_hintmap_insertHint', and the like being used, which account for a
> sizeable chunk of time.
>
> I will investigate this further. Probably the `hinted' flag is being
> ignored somehow.

Some success here.

Disabling hinting stuff properly when hinting is off gave a speed
boost of about a third. Still not as much an improvement as turning
off hinting in the old engine.

Here is my data from testing:
FT_Load_Glyph:`adobe' (units: us/op)
flags  time
0x07.844
0x15.212
0x25.079

I've pushed the code changes to `ewaldhew-wip'. Please check.

Ewald

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

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

[Ewald Hew]

> 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 statistics for bash, libc, etc instead. Strangely it
captures around 5 or 6 processes. I then switched to using
freetype2-demos/bin/.libs/* which were captured properly and only
produced one output file.

> By the way, there is this outstanding bug
> https://savannah.nongnu.org/bugs/?43248. Perhaps you can profile the
> engine and post the details.

Yes, that is the bug I am referencing here.

Ewald

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

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

[Ewald Hew]

>   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!).

Now I have that the glyphpath procedures take a bulk of the time.
What's interesting is the hinting functions get called from these,
regardless of the load flags, and probably explains why it's roughly
the same hinted or not. This seems wrong IMO, as we should be ignoring
hints accordingly, but the call graph shows `cf2_hintmap_build',
`cf2_hintmap_insertHint', and the like being used, which account for a
sizeable chunk of time.

I will investigate this further. Probably the `hinted' flag is being
ignored somehow.

As for FT_DivFix, maybe it is a good idea to optimize this but this
kind of specific optimization is somewhat beyond me right now... might
be an area for me to research into first.

Ewald

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

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

[Ewald Hew]

>   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 denied
 make: *** No rule to make target 'builds/unix/unix-cc.mk'.  Stop.

After running `configure' in freetype root directory, it gives me
 make: Nothing to be done for 'devel'.

Ewald

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

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

[Ewald Hew]

> 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

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

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

[Ewald Hew]

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
hints at the start.

> 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 information. I'm trying to fix that right now.

I have noticed that FT_DivFix (and it's callees) account for a decent
proportion of the runtime, around 18% or so.

Ewald

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

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

[Ewald Hew]

> 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 bad glyphs, and they render fine
now, with the correct initial hintmap.

One issue remains, from MunhwaGothic if you recall, the right pointing
hand (U+261E). I checked against another font, which looks fine. From
the debug output, it's likely the former has bad/insufficient hints,
and perhaps the Adobe hinter is slightly overzealous in moving points.

In this case, it is better to use the autohinter or turn off hinting,
but I wonder if we could, or should, detect such a case, or to leave
the judgement call to the user?

OTOH, it only goes messy at low ppem, at usual reading sizes, the
wonkiness is considerably less. Perhaps nothing needs to be done (the
fault does lie with the font...).

Ewald

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

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

[Ewald Hew]

>> 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 monochrome images...

Never mind, I wanted to have the same conditions as my ftgrid/ftview
results so as to compare on the same basis, but I'll just change those
to LCD mode instead.

> Attached are two solutions for xelatex; [...]

Thanks, I'll try it.

> OK.  So it seems we have to go this route.  Given that Type 1 fonts
> are no longer important today (combined with faster and faster
> computers), we certainly can live with a second pass.

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

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

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

[Ewald Hew]

> 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 certainly simple enough. A
Type1->CFF converter only needs to collate hints when there is a hint
change, replacing it with the appropriate `hintmask' command and later
insert the entire list of hints into the front of the charstring, so
can be done in a single pass. Effectively, converters do nothing with
outline commands. Our complication is that we must be placing outline
points alongside reading the hints, and adjusting the former
accordingly.

>   . Test with Acroread whether Type1 fonts and its CFF conversions
> yield identical rendering results.

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). They're certainly the two different formats
(looking at the line gap), and the problematic glyph "u" looks hinted
correctly. However, to reproduce the results from ftgrid, I'll need it
to render in monochrome. What do you do to test fonts with Acroread?

>   . Try a program like `cfftot1' (from TeXLive or the LCDF bundle) to
> do the opposite conversion, again checking with Acroread for
> identical results.

The CFF->Type1 conversion is what I've already done to obtain the
comparisons. Again, not sure how to test using Acroread. If only there
is a utility that could take in a font file, and generate a pdf with
all glyphs?

>   . Compare conversion results between different tools, for example,
> Adobe's `tx' tool, fontforge, and maybe others.  Maybe this gives
> further hints how Type1 fonts should be handled within a CFF
> environment.

On default settings, both `tx' and fontforge put the hints at the top
of the charstring, as they should. The generated `hintmask' commands
are the same too. Only difference seems to be that fontforge
subroutinizes outline commands (which I'm sure `tx' does too, with the
right options set). Here's the plaintext output converted from
`ztm-Reg.pfb', glyph "u". The original Type1 renders bad, but
both converted CFF render fine.

Fontforge:

  -13 -10 58 -12 14 386 14 hstemhm
  80 84 178 84 hintmask 0000
  488 50 rmoveto
  -35 callsubr
  hintmask 10111000
  -34 callsubr
  hintmask 0000
  -33 callsubr
  endchar


tx:
[86]={
  -15 -10 58 -12 14 386 14 hstemhm
  80 84 178 84 hintmask[78]
  488 50 rmoveto
  -5 hlineto
  -49 2 -7 8 -1 47 rrcurveto
  343 -158 -17 vlineto
  62 -3 12 -10 -50 vvcurveto
  -235 vlineto
  -28 -5 -14 -14 -11 vhcurveto
  hintmask[B8]
  -22 -27 -31 -12 -30 hhcurveto
  -39 -32 34 42 hvcurveto
  326 -146 -14 vlineto
  47 -2 14 -14 1 -48 rrcurveto
  -252 vlineto
  -79 48 -51 73 37 39 16 27 27 vhcurveto
  43 43 rlineto
  -83 vlineto
  4 -2 rlineto
  hintmask[78]
  50 20 36 11 51 14 rrcurveto
  endchar
}

What I draw from this is that a bad Type1 font (actually not the font,
but the way we do hinting doesn't allow mid-charstring hints)
can be made compliant to the spec, i.e. all hints declared at
the start by, and only by, making an extra preprocessing/conversion
pass.

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

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

[Ewald Hew]

>> 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 from another font (ztm-Reg):

T1_Load_Glyph: glyph index 86  | cff_glyph_load: glyph index 86
Initial hintmap  Initial hintmap
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
 0.00 0.00655  gbLS|-10.00 0.00655  pbL
   > 48.0058.00655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
 0.00 0.00731  gbLS|-10.00 0.00655  pbL
   > 48.0052.54723  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.0040.99655  pb  | 36.0046.00655  pb
50.0054.99655  pt  | 50.0060.00655  pt
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.00 0.00655  pb  | 36.0086.05655  pb
50.0011.45801  pt  | 50.00   100.05655  pt
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
   -10.00 0.00655  pbL  -10.00 0.00655  pbL
48.0058.00655  ptL   48.0058.00655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
   -10.00 0.00655  pbL  -10.00 0.00655  pbL
48.0052.54723  ptL   48.0052.54723  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
Hints:   Hints:
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.0040.99655  pb  | 36.0086.05655  pbL
50.0054.99655  pt  | 50.00   100.05655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
(adjusted)   (adjusted)
  csCoord  dsCoord  scale  flags   csCoord  dsCoord  scale  flags
36.00 0.00655  pb  | 36.0086.05655  pbL
50.0011.45801  pt  | 50.00   100.05655  ptL
   436.00   486.27655  pbL  436.00   486.27655  pbL
   450.00   500.27655  ptL  450.00   500.27655  ptL
ptsize =10   ptsize =10
Execution completed successfully.Execution completed successfully.

The initial hintmap is wrong, affecting the first set of hints. Because the
(-10,48) pair is not in the first hint group, but is in a blue zone (hence
locked and in the initial map). For Type 1, the interpreter cannot know
this
until later in the charstring when that pair is actually inserted, and
hence
cannot possibly build the correct initial hintmap unless a preliminary pass
is made to collate all the hints.

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

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

[Ewald Hew]

> 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 everything. The only option I changed from
master branch is defining FT_DEBUG_LEVEL_TRACE.

Then I ran:
 $ valgrind --tool=callgrind bin/ftbench -b a -f 1 ~/SourceHanSans-Regular.otf
 $ kcachegrind

valgrind is of version 3.10.0 and kcachegrind is of version 0.7.4kde

In other words, I'm running with mostly default settings, and the
documentation for callgrind did not mention any special steps to take,
it seemed like it should have worked straight out of the box...

Ewald

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

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

[Ewald Hew]

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

Refer to diff.txt. 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. diffshort.txt is the
same but suppresses differences in `index' and `flags' for less
clutter.

For glyphs that are rendering wrongly, the initial hintmap is
different in Type 1 and CFF versions of the fonts.

I eliminated other possible causes of differing blue zones, hint
order, during hint adjustment, etc., and found that errors occur when
mapping from CS to DS coordinates while the hints are being inserted
(cf. pshints.c:644~ (cf2_hintmap_insertHint)).

So, if the initial hintmap is wrong, the DS coordinates will generally
be wrong. See glyphs index 126 and 134. The initial dsCoords are
wrong, but sometimes after adjustment they are the same, more on that.

Now, only some hints are moved wrongly (cf2_hintmap_adjustHints).
Lines 14~27 is one example where hints are still correct after
adjustment. Lines 61~62, 68~69 is one example where this goes wrong.
(The other hints in this group differ too of locking). Note how hint
#2 has been adjusted downwards but hint #7 upwards, i.e., the error
was large enough that it went into the next "adjustment zone".

There is also a minor issue where stem hints never get locked in Type
1, since hint changes always remake the list of hints completely.
However, I don't think this causes problems if the initial hintmap is
correct (performance? adjustment must be done again). Example: Renders
correctly, glyph index 131, lines 277~292.

> I guess it's not `FT_Load_Glyph' but rather `FT_Get_Advance' that
> might cause slow-downs.  Behdad?

Hmm, the original bug report was for loading though (running ftbench
with `-b a').

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

Ewald
FT_Stream_Open: could not open `/home/ewaldhe | cff_glyph_load: glyph index 126
FT_Stream_Open: could not open `/home/ewaldhe <
T1_Load_Glyph: glyph index 126<
Initial hintmap Initial hintmap
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
  > 6 672.00   739.44
655  pbL
  > 6 733.00   800.44
655  ptL
(adjusted)  (adjusted)
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL | 0   0.00 0.00
721  gbL
  > 6 672.00   739.44
655  pbL
  > 6 733.00   800.44
655  ptL
Hints:  Hints:
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
1 120.00   120.00655  pb  | 1 120.00   135.16
655  pb
1 181.00   181.00655  pt  | 1 181.00   196.17
655  pt
2 252.00   252.00655  pb  | 3 252.00   280.52
655  pb
2 314.00   314.00655  pt  | 3 314.00   342.52
655  pt
(adjusted)  (adjusted)
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00759  gbL   0   0.00 0.00
759  gbL
1 120.00   139.11655  pb1 120.00   139.11
655  pb
1 181.00   142.01923  pt1 181.00   142.01
923  pt
2 252.00   300.16655  pb3 252.00   300.16
655  pb
2 314.00   362.16655  pt3 314.00   362.16
655  pt
Hints:  Hints:
  index  csCoord  dsCoord  scale  flags   index  csCoord  dsCoord  
scale  flags
0   0.00 0.00655  gbL   0   0.00 0.00
655  gbL
1 133.00   133.00655  pb  | 2 133.00   148.82
655  pb
1 181.00   181.00655  pt  | 2 181.00   196.82
655  pt
2 252.00   252.00655  pb  | 3 252.00   300.16
655  pbL
2 314.00   314.00655  

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

[Ewald Hew]

> 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
>
> then pressing key `f' to enforce full auto-hinting.
>
> As you can see, it is quite detailed.
> Table of points:
> Table of horizontal segments:
> Table of vertical segments:
> Table of horizontal edges (1px=48.13u, 10u=0.21px):
> Table of vertical edges (1px=50.00u, 10u=0.20px):

These would be really useful, I guess I'll start by adding something
of this sort to the Adobe hinter too. I somehow hadn't seen these
tables before, despite running with "any:7" most of the time.

> A starting point might be running ftbench with a profiler.  I
> sometimes use valgrind for that:
>
>   valgrind --tool=callgrind ...
>
> The resulting data can then be visualized with `kcachegrind'.  There
> are certainly other profiling tools that you might find helpful.

Thanks for the advice!

Ewald

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

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

[Ewald Hew]

A quick update on stuff.

I've pushed the changes adding CID font support to `ewaldhew-wip'. It
was a simple change by just following what I'd already done with the
`type1' module. Comparison images attached.

I've also pushed a few more cleaned commits to `ewaldhew-cleaned'.
More are on their way..

Ewald


https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Virus-free. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com



___
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

[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

[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

[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

[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

[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

[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

[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

[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

[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

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

[Ewald Hew]

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

Re: [ft-devel] [GSoC] Updates and quick question

[Ewald Hew]

> [Please *always* report such issues to the mailing list!  I consider
>  it an important part of GSoC that the community stays informed,
>  possibly discussing the issue.]

Oh no, sorry about that! I'd initially wrote this as a reply to the
previous thread but spun it off into a new mail, and had forgotten to
copy over the Cc: field. I have to pay more attention to these
things...

> Thanks!  Will check later.

Thanks! I hope there isn't any problem with the rebase due to the
removal of `OVERFLOW_' from the new macros.

> This I don't know.  Ideally, everything should be unified that can be
> unified.  The basic question is how much similarities in the code are
> present, and how much unification makes actually sense.

Yes. However, right now I don't yet fully understand the abstraction
between the FreeType public API and the internal driver objects, such
as how glyph data in the driver gets out to the API layer.

I get that each driver handles its own objects, so using the same
object for either Type 1 or CFF seems wrong as we have separate stuff
for different formats, i.e. `T1_Builder_Funcs' and
`CFF_Builder_Funcs', etc. In other words, since the `type1' driver
outputs to `type1' objects and the `cff' driver outputs to `cff'
objects, routing Type 1 data through the CFF interpreter without
changing the way it connects with the API would cause the results to
be output to `cff' objects instead, which isn't intended.

Correct me if I'm wrong, but that might essentially meld the two
drivers together (and `psaux' wouldn't really be auxiliary any more).
Although, perhaps that is the direction you are aiming for?

> My original, vague idea was to prepare Type 1 data (not thinking about
> what `prepare' exactly means) so that it can be accepted by the CFF
> interpreter, which in turn gets slightly extended where necessary to
> handle Type 1 data.

So, right now the interpreter takes in CFF charstring data and
performs actions on the `cff' objects via the callbacks. If I now pass
in Type 1 data (assuming it's already been extended), I should expect
to perform actions on `type1' objects instead.

My idea is to add two modes to the functions being called by
`cf2_interpT2CharString', much like how it has two modes (soon three)
itself, for either CFF or Type 1, and hence output to the right place
without having to change the low-level APIs. An alternative idea is to
make `cf2_interpT2CharString' call either `cff' functions or `type1'
functions depending on the mode passed into it. This is just shifting
the position of added code though.

What do you think?

Ewald.

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

Re: [ft-devel] [GSoC] Moving CFF stuff into psaux module

[Ewald Hew]

> OK.  Here a minor patch.
>
>
> diff --git a/src/cff/cffgload.c b/src/cff/cffgload.c
> index c27f74c3..e4721d74 100644
> --- a/src/cff/cffgload.c
> +++ b/src/cff/cffgload.c
> @@ -203,7 +203,7 @@
>  FT_Bool  hinting, scaled, force_scaling;
>  CFF_Font cff  = (CFF_Font)face->extra.data;
>
> -PSAux_Servicepsaux = face->psaux;
> +PSAux_Servicepsaux = (PSAux_Service)face->psaux;
>  const CFF_Decoder_Funcs  decoder_funcs = psaux->cff_decoder_funcs;
>
>  FT_Matrixfont_matrix;

Thanks for spotting that! I must have missed it while changing the
struct definitions halfway through.

> Please do logical, smaller commits.  Simply add a sentence to the log
> message about not being able to compile the current commit.

Ok, will do.

> So it seems that you have already done a big step into the right
> direction.  Two main issues are still to tackle, right?
>
> . Handle `cid' module.
>
> . Make the cff hinter handle Type1 (and CID) fonts also, as an
>   alternative to the `pshinter' module.

Indeed. I will be working on the latter first.

Ewald.

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

Re: [ft-devel] [GSoC] Moving CFF stuff into psaux module

[Ewald Hew]

> I've now looked at the code.  Sorry for the delay.
>
> Everything looks very good, thanks!  Some comments.

Thanks!

> . If you are going to clean up, please replace the `cf2' file name
>   prefix with something more generic.

I think s/cf2/ps for the file names should be fine?

> . Recently, integer overflow run-time checking was activated (again)
>   for the fuzzer, causing a lot of minor code changes while applying
>   fixes.  I'm not going to do large structural changes to the CFF
>   stuff (this would be mean :-), so you might decide to apply those
>   changes later on while doing the clean-up.

I have rebased onto latest and did a force push (this branch is meant
to be disposable). I hope that is fine.
Either way, I have gotten freetype building again, and from a cursory
inspection using the freetype demos, everything seems to work fine. I
can't tell if I may have introduced any subtle bugs, how can I make
use of the testing suite to rigorously confirm this?

The main changes from last time are:
(1) Added a new service in `cff', FT_Service_CFFLoad, providing
functions from `cff/cffload' to `psaux'
(2) Moved all the CFF struct definitions from cffobjs.h and cfftypes.h
to freetype/internal, so that the cff functions in psaux can access
them as well.

(1) is as advised previously, whereas (2) was necessary to make the
project build again. I do wonder if it may have been too extreme to
move all the definitions over, but I could not come up with a better
solution.

I will do a cleaned commit with proper changelogs once I can confirm
that functionality is as it is before all my changes. Would you prefer
that I squash everything into a single commit, since it does not
compile on intermediate commits, or to separate changes in some
logical manner, e.g. grouped by the specific component I was pulling
out from `cff' ?

Ewald

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

Re: [ft-devel] [GSoC] Moving CFF stuff into psaux module

[Ewald Hew]

>
>>  - It seems to be better to move the blend functions to the psaux
>>service (except cff_done_blend and cff_blend_doBlend)
>
> What functions exactly do you mean?

I'm referring to these:
  cff_blend_check_vector
  cff_blend_build_vector
  cff_blend_clear
  cff_get_var_blend
  (and by extension cff_load_private_dict)
which are being called from the cf2 side. These support the CFF2 blend
operator, and could be moved to psaux as with the other charstring
parsing stuff, i.e. builder functions. Correct me if I'm wrong.

> ... I agree with you that (c) sounds best.  FreeType is full of
> function pointers, so there is no reason to not use them :-)
>
> Actually, I suggest (c'): Both CFF and Type1 provide a service for
> those function pointers, which would lead to the following structure
> (please adapt the service names to your taste).
>
>   CFF and Type1: provide `postscript-parse-funcs' service
>   psaux: provide `postscript-charstrings-parse' service
>
> Both CFF and Type1 would call `postscript-charstrings-parse', which in
> turn calls `postscript-parse-funcs' – the already existing service
> management code would automatically use the stuff from the CFF or
> Type1 version of `postscript-parse', depending on the module.

I'm not sure I understand fully... What I get is to provide the
`parse_charstrings' function from psaux, which is already being done
(decoder functions in the psaux module interface). I'm not sure what
is in `type1' that still needs to be used in psaux (save the single
function stored as parse_callback in T1_DecoderRec), but for `cff',
instead of passing the relevant functions from `cffload' as parameters
to the init function, I should just create a CFF module service in the
same way as psaux is (placing cffmod.h in include/freetype/internal/).
Am I right?

What justifies creating a new service which will only be used by one
other module, as opposed to passing in a table of function pointers as
callbacks during init? Is this a matter of best practices / design
philosophy?

> Honestly, this is a matter of taste, and maybe it makes sense to
> follow the pseudo-C++ stuff already present in FreeType; see
>
>   https://www.freetype.org/freetype2/docs/design/design-3.html

Hmm, following this design I would do something like:

struct PS_DecoderRec {
  FT_Bool  isCFF;

  PS_Decoder_Zone*  zone;
// CFF_Decoder_Zone and T1_Decoder_Zone have the same fields, only
difference is the values of MAX_SUBRS_CALLS

  FT_Int flex_state;
  FT_Int num_flex_vectors;
  FT_Vector  flex_vectors[7];

  FT_Render_Mode hint_mode;

  FT_Boolseac;
}
struct CFF_DecoderRec {
  PS_DecoderRec  root;

  /* All the other fields
   *   ...
   */
}
struct T1_DecoderRec {
  PS_DecoderRec  root;

  /* All the other fields
   *   ...
   */
}

which sort of strikes a middle ground between the two strategies.
Then we would first pass a PS_Decoder to
cf2_decoder_parse_charstrings, check its isCFF flag, and cast it to
either CFF or T1.

Also, I just pushed the changes I have tried making thus far to
savannah, in branch ewaldhew-refactor-cf2 (not cleaned). If possible,
please give it a quick look to see if I am going in the right
direction. (Most of the changes are cut-and-paste)


Ewald

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

[ft-devel] [GSoC] Moving CFF stuff into psaux module

[Ewald Hew]

Werner and Alexei,

Apologies for my somewhat long period of silence. I have been studying
the code and needed time to organise my findings and thoughts. To
start off, I have a couple of questions.

I have started pulling out the code for cff charstring processing into
the psaux module, and most of it separates quite cleanly - with the
exception of cff/cffload. Here are my considerations:

 - The cff code moved to psaux still uses functions defined in
cff/cffload.h. However, some cff code not moved is also sharing some
of these.
 - Notably, some of the cff/cffload functions are used in
cff/cffparse, and vice versa. ( cff_parser_run also makes a call to
cff_decoder_parse_charstrings (now inside psaux) if
CFF_CONFIG_OPTION_OLD_ENGINE is defined, but I'm guessing we don't
have to continue supporting this? )
 - It seems to be better to move the blend functions to the psaux
service (except cff_done_blend and cff_blend_doBlend)

I have considered doing the following:

 a. Move cffload and cffparse into psaux as well - providing the
functions cff module needs via the psaux service interface. Perhaps
the more extreme option, although simple in concept.

 b. Only move the parts of cffload that are used in psaux (after
splitting) there (blend functions, cff_random, etc.) which can be
provided to cff module via the service interface. Leave cffparse in
cff and pass relevant functions in as callbacks. However, this might
not be possible without also ensuring psaux/new_cffload has access to
the Parser struct definitions too (move into internal/cfftypes.h or
something).

 c. Pass all relevant functions from cff into psaux as callbacks
during initialisation. From what I see, this seems to be doable by
storing the functions in either decoder->cff or
decoder->cff->cf2_instance.data, during initialisation in
cff_slot_load.

So (c) seems to be the option, although it does involve throwing about
another whole bunch of function pointers. What do you think? Is there
a more conservative approach?

The next question concerns the merging of the two code paths of type1
and cff glyph loading. For now, the most obvious difference is in the
respective decoder objects, and cf2_decoder_parse_charstrings should
be able to accept either. I cannot be convinced as to which of the two
below is the better strategy, although I am leaning towards the
former.

Pass them in as void* so as to cast them to either T1_Decoder* or
CFF_Decoder* depending on a isCFF flag.
OR
Create a new structure PS_Decoder combining the two (perhaps have
nested structs with the format-specific fields, which is most part of
the decoders). Again, an isCFF flag will determine which fields are
being used.

The former is simple but perhaps less safe, but there are a few ways
to implement the latter. Which is better?

I would appreciate your input on these.

Regards,

Ewald

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

Re: [ft-devel] GSoC 2017 - CFF for Type 1

[Ewald Hew]

> Regarding modularity, the constraint is rather simple: [...]

Aha, I understand now. Thanks for the informative reply!

> Thanks, looks promising!  Please transfer this to a proper, registered
> GSoC draft proposal as soon as possible.  After the transfer, please
> allow comments for the corresponding google doc so that I can write
> something.

I have done the above. Do note that the location of the file has changed.
The currently registered one on GSoC portal is the right one.

Regards,
Ewald

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

Re: [ft-devel] GSoC 2017 - CFF for Type 1

[Ewald Hew]

On Sun, Mar 26, 2017 at 1:52 AM, Werner LEMBERG  wrote:

>
> > I need some time to cross-reference the specifications to decide if
> > this is possible.  The alternative is, as how CFF2 support was
> > added, to write a separate interpreter for Type 1 charstrings and
> > glue it to the CFFBuilder using callbacks (I am still trying to
> > understand the CF2 side, would appreciate clarification if this is
> > not how it works).
>
> I think this would lead to a lot of code duplication, buy maybe this
> is a cleaner solution.  Something to investigate...
>
> From what I understand, we can rewrite 't1_decoder_parse_charstrings' to
do the same as 'cf2_interpT2CharString' for calling outline builder
functions, which does not increase duplicated code over what is already
present. Then, for hinting, I believe we can do the same i.e. get the t1
decoder to use the new hinter over 'pshinter', except I am having some
trouble figuring out how the CF2 hinter works...(specifically, how are the
hinter functions actually called). This approach merges processing for
type1/cff fonts only after the decoding stage, i.e. one type of charstring
to one decoder. This sort of ties in with the second method I mentioned in
my opening post.

The alternative below merges before the decoding stage, i.e. use the same
decoder for all three types of charstrings, which I understand more readily
and am leaning towards.

Yes, the interpreter should understand Type 1, Type 2, and CFF2
> charstrings – in three different modes.  In other words, you would
> have to add a third mode to `cf2_interpT2CharString'.
>


> Mhmm.  I would like to retain the modularity of FreeType, so it might
> be better to change
>
> [...]
>

What do you think?  The first step would then be to split off the CFF
> charstring and hinting stuff from the `cff' module into a new module
> `new_psaux' (please find a better name :-).


However, I don't quite understand the "modularity" part. I imagined
extending 'cf2intrp' with an additional T1 mode, and adapting the T1 data
structures (e.g. the Font and Decoder records) to work with this change. My
guess is that enough functionality is added that the new type1/cff joint
interpreter should be viewed as a separate module, but I am not sure what
the benefits are, as I have never dealt with such a large-scale project and
am not used to best practices.

Also, here is a rough proposal draft that includes the tasks identified
thus far. https://goo.gl/rINYUZ

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

[ft-devel] GSoC 2017 - CFF for Type 1

[Ewald Hew]

Hi all,

I am Ewald, a Computer Science student and I am interested in working with
FreeType for GSoC 2017. I am looking at the idea of adding Type 1 support
to the CFF driver.

I have read through some parts of the code and have a rough idea of how
things connect to one another. I thought of two possible ways to add Type 1
support. First, to rewrite the Type 1 decoder to translate Type 1
charstrings to Type 2, which the CFF driver can understand. Second, to
adapt the Type 1 decoder to produce hinting output that can be used by the
CFF driver. I ruled out the first option as it adds an additional layer of
'decoding' and does not seem efficient. Hence, I am leaning towards the
second method and am in process of figuring out the differences between the
hinter output of CFF and Type 1 decoders.

I am still trying to get a full picture of what this task would require and
wonder if I am going in the right direction. I recognize that this is
tagged as 'hard' and I fear I may have missed things that make it more
difficult than I imagined. I would really appreciate any guidance or
comments. Thank you.

Regards,
Ewald Hew
(Undergraduate in CS, National University of Singapore)
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/freetype-devel