Re: any small software to test the incremental loading feature?

[suzuki toshiya]

Hi,

Finally, I concluded that GhostScript never uses the incremental loading 
feature in cid_glyph_load(). The mechanism is below.

* The incremental loading of CIDFontType 0 (a.k.a. FontType 9) is described in PostScript language 
reference pp.352-356 and pp.375-377. In the "incremental loading" ("incremental 
definition," in PLRM terminology), the PostScript interpreter pushes the Type1 CharString 
glyph data for a specific glyph to the GlyphDirectory dictionary or array in the FontType9 
dictionary. There is no particular operator to do such an operation; regular PostScript operation 
would do.

* Because the procedure to insert the Type1 CharString glyph data is implemented by a regular 
PostScript program, we could not assume its representation (in the original PostScript document) is 
sufficiently raw & straightforward like that for Adobe Type Manager. For example, the part 
inserting the "一" glyph description is below (1200 is the CID for "一", in 
Adobe-Japan1 system):

%ADOBeginSubsetFont: IXYEVX+WadaGo-Bold-90msp-RKSJ-H-Identity-H AddGlyphs
Adobe_CoolType_Utility begin ct_MakeOCF begin
%ADOt1write: (1.0.24)
ct_GlyphDirProcs begin/IXYEVX+WadaGo-Bold-90msp-RKSJ-H 1 GetGlyphDirectory
1200 <041C60D8A8C9B5EE310DFF523C01B442319EB5152EBC5E42B2C8288176
4C52> |
!
end
end end
%ADOEndSubsetFont
reset_gvm
/IXYEVX+WadaGo-Bold-90msp-RKSJ-H-Identity-H findfont (snip)

Here, "Adobe_CoolType_Utility", "ct_MakeOCF", "ct_GlyphDIrProcs", "|", "!", and 
"reset_gvm" is the macro operators defined in the PostScript program named "Adobe CoolType Utility." It might be popular, but it 
is not a practical idea to make FreeType understand these operators directly.

* Therefore, we should let the PostScript interpreter reconstruct the CIDFontType 0 
dictionary without the help of FreeType. Does the PostScript interpreter need the 
incremental loading feature for CIDFontType 0? The PostScript interpreter already 
has the subset & self-standing font dictionary.

* The procedure in GhostScript is below.

1) A GS-specific operator, ".type9mapcid," extracts the Type1 CharString for a specified 
CID from a selected CIDFontType 0 dictionary. Its internal is described in zfcid0.c. This operator 
works with the font dictionary loaded on the PostScript language space, not only with the 
disk-resident font file. The "incrementally updated" font object is already in the 
PostScript language space. Its implementation is a function ztype9mapcid(), which is written fully 
in C and can be invoked from C language space if the PostScript language context is correctly 
specified.

2) zFAPIBuildGlyph9() is invoked to execute "show" or other operations to have 
an outline of a specified glyph in a specified font. zFAPIBuildGlyph9() invokes 
ztype9mapcid() from its C language space and retrieves the Type1 CharString to be 
rendered, with no help of FreeType.

3) How does GhostScript use FreeType to render the retrieved Type1 CharString? 
GhostScript makes a Type1 (not Type9) PostScript font on the memory (which 
includes some properties and subroutines taken from the FDArray) and passes it 
to FreeType (type1 driver, not t1cid driver). GhostScript provides its glyph 
description data by the callback function of FreeType's incremental loading 
feature (t1gload.c::T1_Parse_Glyph_And_Get_Char_String()) dynamically. 
Therefore, there is no need to repeat FT_Open_Face() for this synthesized Type1 
font when GS replaces the glyph description data. If you check FT_Load_Glyph() 
argument, you can find the glyph_index in its argument is always 0.

* In summary, the current GhostScript will never use the incremental loading 
feature in the t1cid driver of FreeType. In addition, I'm questioning whether 
the incremental loading feature of t1cid is helpful to render the PostScript 
document using the incremental definition of the CIDFontType 0 dictionary.

If anybody knows a practical use case, please let me know.

Regards,
mpsuzuki

On 2023/04/27 21:40, suzuki toshiya wrote:
> Hi,
>
> Recently, Alex gave me an idea to improve FT_Get_CID_From_Glyph_Index() API for 
> CID-keyed font Type 0 (FontType 9, the most traditional CID-keyed font using 
> PostScript Type1 CharStrings) by adding a fallback to CID=0 for the cases that 
> the requested GID points to a broken entry providing no glyph data. 
> cid_load_glyph() can catch such an error but cannot stop the Type1 CharString 
> rendering after successful loading. Therefore, using cid_load_glyph() for 
> validating CID is too expensive; FT_Get_CID_From_Glyph_Index() is interested in 
> the presence of the glyph data but has little interest in its rasterization 
> result. For simple checking of the presence of the glyph data, I propose to 
> separate the glyph data loading part of cid_load_glyph() as 2 helper functions; 
> one is for incremental loading, another is a traditional disk-resident font 
> file. I drafted a few patches:
>
> https://gitlab.freedesktop.org/mpsuzuki/freetype-mps-wip/-/compare/master...wip-t1cid-separate-loaders-of-fd-offsets?from_project_id=11053&straight=false
>
> But I need a good testing tool to check the possible regression for the 
> incremental loading. One of the most straightforward ideas would be using 
> GhostScript and some PostScript data generated by legacy printer drivers (which 
> can emit the per-glyph Type1 CharString and embed it to the output but cannot 
> make a self-standing CID-keyed font like that in PDF). But it is too big 
> software. I wish there were smaller - no need to render seriously - testing 
> tools. I tried to find something in the mailing list archive around 2002 
> Jun-Jul (when the main trunk merged the incremental loading feature, 22 years 
> ago!), but I could not find anything. Please let me know if anybody can 
> remember how the developers tested in those days.
>
> Nothing to say; I've already tried GhostScript. But GhostScript uses 
> t1_load_glyph instead of cid_load_glyph.
>
> The client of FreeType's incremental loading feature.
> https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=base/fapi_ft.c;hb=HEAD
>
> The emitter of the font stream for the FreeType.
> https://git.ghostscript.com/?p=ghostpdl.git;a=blob;f=base/write_t1.c;hb=HEAD
>
> There is an emitter of the incremental downloading font dictionary for 
> PostScript Type1 font, write_t1.c written by Graham Asher himself), but there 
> is no emitter for Type9 font (CIDFontType0 font).
>
> Regards,
> mpsuzuki