View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000967luatexluatex bugpublic2016-03-03 08:242016-03-10 17:04
ReporterDohyun Kim Assigned ToHans Hagen  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Fixed in Version0.89.0 
Summary0000967: "bad glyph index" error upon using some cid-keyed opentype fonts
Descriptionwhen compiling an MWE with luatex 0.89.2

\font\1={NotoSansKR-Regular.otf}
\1
龍
\bye

I get a fatal error:

! error: (file ./NotoSansKR-Regular.otf) (cff font): bad glyph index 47434
! ==> Fatal error occurred, no output PDF file produced!

The font used in MWE is available at
https://raw.githubusercontent.com/googlei18n/noto-cjk/master/NotoSansKR-Regular.otf
Additional InformationIt seems to be related to the svn revision 5756.
https://foundry.supelec.fr/scm/viewvc.php?view=rev&root=luatex&revision=5756
TagsNo tags attached.

Activities

Hans Hagen

2016-03-03 18:40

manager   ~0001586

it seems to depend on the version of the font

\enabletrackers[fonts.missing=replace]
\font\1=file:notosanskr-regular.otf\1
\startTEXpage[offset=10pt]
⿓ (U+02FD3) 龍 (U+09F8D) 龍 (U+0F9C4)
\stopTEXpage

and we've seen bugged version in the past; in the case of an aborted run there is a bad glyph index involved (could be a notdef/zero issue or whatever)

Hans

Dohyun Kim

2016-03-04 02:07

reporter   ~0001587

Last edited: 2016-03-04 02:17

 The font I used is up-to-date version 1.004, so the version of font is irrelevant. And the font evidently has glyph 龍 (U+09F8D), I'm sure.

Compiling the mwe of mine with luatex-plain results in a fatal error; compiling it with context results in .notdef when opened in Adobe Reader. There must be something wrong.

For instance, we get unexpected glyph with the following example

\startTEXpage[offset=10pt]
\definedfont[file:notosanskr-regular.otf]
一 U+4E00
\stopTEXpage

The original glyph, 一 U+4E00, has its cid 9831 and gid 2427;
the resulted glyph, ㏽ U+33FD, has its cid 2427 and gid 2377,
where "gid" means "orig_pos" in luatex's term.
So there seems to be a confusion between cid and gid in the engine or in the fontloader.

Hans Hagen

2016-03-04 14:51

manager   ~0001588

we tested with several variants of notosanskr-regular and all behave differently

notosanscjkkr-regular.otf

seems to be ok

Dohyun Kim

2016-03-05 03:55

reporter   ~0001589

it's because every glyph in notosanscjkkr-regular.otf has identical index numbers regarding cid and gid, which is not the case with notosanskr-regular.otf.

Now that fontloader is requesting gid, not cid anymore, for inclusion in final pdf (which is an improvement, I think), it seems that the routine that converts cid into gid should be removed from writecff.w.

Hans Hagen

2016-03-05 13:26

manager   ~0001590

i played with the lua code for more than a day now, tries several things, checked unicode->index mappings etc ... the problem is that ff follows a different route in resolving indices (not clear to me what, but the kr and cjkr are differently encoded (subfonts) so it's a pain to trace) ... i get the impression that we can be dealing with a mix of fflib and luatex backend mixup here (so for some cases ff gives a gid that is not ok but the backend magick turns it to a proper one; in other cases we provide the right one and the backend magick messes it up)

so a first step is to fix the backend ... what code lines in writecff do you refer to

then we can make sure the ff loader matches it (so that we stay closer to the standard)

Hans Hagen

2016-03-05 13:47

manager   ~0001591

Last edited: 2016-03-06 15:48

 patches submitted

Dohyun Kim

2016-03-07 07:38

reporter   ~0001592

It seems that revision 5823, parsettf.c, lines 3676--3678 sould be reverted to the previous version. Because of this patch, the last subfont has disappeared from the table returned by luafontforge.

Hans Hagen

2016-03-07 09:27

manager   ~0001593

which glyph is that? btw, there is a later patch that fixes min/max values

Dohyun Kim

2016-03-07 10:14

reporter   ~0001594

for instance, glyph id 24397 (cid 65166) of notosanskr-regular.otf and many others for vertical rendering of Japanese Kana.

see line 3676 of revision 5823
( https://foundry.supelec.fr/scm/viewvc.php/branches/experimental/source/texk/web2c/luatexdir/luafontloader/fontforge/fontforge/parsettf.c?root=luatex&r1=5823&r2=5822&pathrev=5823 ).

for ( j=0; subdicts[j]!=NULL; ++j );
     info->subfontcnt = j;

is quite different from

for ( j=0; subdicts[j]!=NULL; ++j ) {
    info->subfontcnt = j;
}

the former is composed of two statements in spite of the indentation of second line.

Issue History

Date Modified Username Field Change
2016-03-03 08:24 Dohyun Kim New Issue
2016-03-03 18:40 Hans Hagen Note Added: 0001586
2016-03-04 02:07 Dohyun Kim Note Added: 0001587
2016-03-04 02:17 Dohyun Kim Note Edited: 0001587
2016-03-04 14:51 Hans Hagen Note Added: 0001588
2016-03-05 03:55 Dohyun Kim Note Added: 0001589
2016-03-05 13:26 Hans Hagen Note Added: 0001590
2016-03-05 13:47 Hans Hagen Note Added: 0001591
2016-03-06 15:48 Hans Hagen Note Edited: 0001591
2016-03-07 07:38 Dohyun Kim Note Added: 0001592
2016-03-07 09:27 Hans Hagen Note Added: 0001593
2016-03-07 10:14 Dohyun Kim Note Added: 0001594
2016-03-07 17:07 Hans Hagen Assigned To => Hans Hagen
2016-03-07 17:07 Hans Hagen Status new => assigned
2016-03-10 17:04 Hans Hagen Status assigned => closed
2016-03-10 17:04 Hans Hagen Resolution open => fixed
2016-03-10 17:04 Hans Hagen Fixed in Version => 0.89.0