View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000931 | luatex | luatex bug | public | 2015-04-18 07:21 | 2015-09-11 22:07 |
| Reporter | Dohyun Kim | Assigned To | Hans Hagen | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000931: wrong glyph mapping upon using some CID-Keyed OpenType fonts | ||||
| Description | For instance, with this CID-Keyed font: https://github.com/adobe-fonts/source-han-sans/raw/release/SubsetOTF/KR/SourceHanSansKR-Light.otf the input string "鹿" (U+9E7F) is currently reprensented as "丱" (U+4E31) in the resulting PDF file. The following file was tested with luatex-plain: %%%%% \font\shskr=SourceHanSansKR-Light.otf \shskr 鹿 \end %%%%%% | ||||
| Steps To Reproduce | A simple lua code (run with texlua): ----- local shskr local font = fontloader.open("./SourceHanSansKR-Light.otf") if font then shskr = fontloader.to_table(font) fontloader.close(font) end local utfchar = unicode.utf8.char local deer_uni = 0x9E7F print("deer unicode:", deer_uni, utfchar(deer_uni)) local deer_gid = shskr.map.map[deer_uni] print("deer glyph id:", deer_gid) for i,v in ipairs(shskr.subfonts) do local deer = v.glyphs[deer_gid] if deer then local deer_uni = deer.unicode print("deer glyph unicode:",deer_uni, utfchar(deer_uni)) end end ----- will print out the followings: deer unicode: 40575 鹿 deer glyph id: 9900 deer glyph unicode: 20017 丱 | ||||
| Additional Information | The font data returned by luatex engine has a glyph table apparently arranged by CID numbers, which is wrong. The index of glyph table should be an array of GID, where no vacancies in-between is allowed. In most CID-Keyed OpenType fonts, CIDs are indentical to GIDs. So no problem with current behaviour of luatex. The font used above, however, has many glyphs of which the GID is not identical to its CID, raising the issue to the surface. | ||||
| Tags | No tags attached. | ||||
|
|
ok, so this is why context sees them as duplicates (i always wondered how that could happen) Hans |
|
|
We have a patch now in experimental, rev. 5249. |
|
|
also need an adaption in the fontloader so best wait with testing till we're ready (also fixing some other issues) |
|
|
this is what has been done: - we have enabled the orig_pos field to get the orginal index - we introduced a minglyph field in the subfonts - maxglyph now indicates the upper index, so one should loop over glyphmin upto glyphmax - glyphcnt reflexts the number of glyphs (for testing as min and max can be both zero) - the table format has been bumped to 0.4 - the context fontloader code knows how to deal with this |
|
|
implemented |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-04-18 07:21 | Dohyun Kim | New Issue | |
| 2015-04-18 14:23 | Hans Hagen | Note Added: 0001355 | |
| 2015-05-14 13:27 | Hans Hagen | Assigned To | => Hans Hagen |
| 2015-05-14 13:27 | Hans Hagen | Status | new => assigned |
| 2015-05-19 09:02 | luigi scarso | Note Added: 0001376 | |
| 2015-05-19 12:09 | Hans Hagen | Note Added: 0001377 | |
| 2015-05-21 13:44 | Hans Hagen | Note Added: 0001382 | |
| 2015-09-11 22:07 | Hans Hagen | Note Added: 0001398 | |
| 2015-09-11 22:07 | Hans Hagen | Status | assigned => closed |
| 2015-09-11 22:07 | Hans Hagen | Resolution | open => fixed |
