Re: [jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
> On 29 Nov 2015, at 15:28, Glenn Adams wrote: > > On Sun, Nov 29, 2015 at 3:05 AM, Andreas L. Delmelle (JIRA) > wrote: > > [ > https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030875#comment-15030875 > ] > > Andreas L. Delmelle commented on FOP-2540: > -- > > > In the other direction, it would likely be very rare situations. I cannot > immediately think of use cases for mapping a single codepoint to more than > one glyph...? > > The function of CMAP is not involved in these types of mappings; rather, the > GSUB table is used. And, BTW, there are many examples of M to N mappings (M > != N). See org.apache.fop.complexscripts.fonts.GlyphSubstitutionTable for > examples. Of course... It occurred to me after having written that comment that there are indeed many examples. The most common ones are letters w/ various accents or diacritical marks, where the glyph for the letter and the one for the accent can be separated in the font. At any rate, that would indeed be more a complex scripts function, so should already be supported. Will still take a look at correcting the situation for mapping different codepoints to the same "8-bit" glyph then, since that definitely does not seem to be functioning properly at this point. BTW - Hope someone in the meantime can already try out the patch on Linux, and see if the support for OTFs is also improved there. I suppose a similar situation exists on that platform, i.e. not all of the system fonts having a Windows/Unicode cmap... KR Andreas
Re: [jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
On Sun, Nov 29, 2015 at 3:05 AM, Andreas L. Delmelle (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030875#comment-15030875 > ] > > Andreas L. Delmelle commented on FOP-2540: > -- > > Thinking some more about the current state of "codepoint-to-glyph" > mappings, and IIUC, the 1-1 correspondence that is currently enforced by > the code would be insufficient for a number of cases, i.e. not only the > extra roman-to-symbol mappings that are supported by Windows and Mac Symbol > fonts. > > I am thinking that, more generally, there may be cases where a font simply > does not have a glyph for a certain codepoint, but wants to map that > codepoint to another glyph. Example would be different types of dashes or > spaces. A non-breaking space could theoretically be mapped to the very same > 'glyph' (representing an empty space, obviously) as a regular space. An > em-dash could be mapped to a regular minus sign. Things like that... This > would not be supported by the current code, if I catch correctly, since as > soon as an "eight-bit-glyph" is mapped once, it cannot be mapped again. > > In the other direction, it would likely be very rare situations. I cannot > immediately think of use cases for mapping a single codepoint to more than > one glyph...? > The function of CMAP is not involved in these types of mappings; rather, the GSUB table is used. And, BTW, there are many examples of M to N mappings (M != N). See org.apache.fop.complexscripts.fonts.GlyphSubstitutionTable for examples. > > > Enhance TTF/OTF support beyond Windows > > -- > > > > Key: FOP-2540 > > URL: https://issues.apache.org/jira/browse/FOP-2540 > > Project: FOP > > Issue Type: Improvement > > Components: font/opentype > >Affects Versions: 2.0 > > Environment: OS X > >Reporter: Andreas L. Delmelle > >Assignee: Andreas L. Delmelle > >Priority: Minor > > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = > 3, i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic > Unicode, or 1, i.e. Macintosh. > > This makes quite some system fonts bundled with OS X supposedly > unusable. The solution is fairly trivial (patch proposal will be attached > shortly), provided the cmap table format in the font is already supported. > FOP currently only has support for cmap format 4 (segment to delta > mapping), but this seems to suffice for most of the Unicode cmaps as well. > > See also FOP-2539, which triggered me to investigate this closer. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
[jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030875#comment-15030875 ] Andreas L. Delmelle commented on FOP-2540: -- Thinking some more about the current state of "codepoint-to-glyph" mappings, and IIUC, the 1-1 correspondence that is currently enforced by the code would be insufficient for a number of cases, i.e. not only the extra roman-to-symbol mappings that are supported by Windows and Mac Symbol fonts. I am thinking that, more generally, there may be cases where a font simply does not have a glyph for a certain codepoint, but wants to map that codepoint to another glyph. Example would be different types of dashes or spaces. A non-breaking space could theoretically be mapped to the very same 'glyph' (representing an empty space, obviously) as a regular space. An em-dash could be mapped to a regular minus sign. Things like that... This would not be supported by the current code, if I catch correctly, since as soon as an "eight-bit-glyph" is mapped once, it cannot be mapped again. In the other direction, it would likely be very rare situations. I cannot immediately think of use cases for mapping a single codepoint to more than one glyph...? > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2540) Enhance TTF/OTF support beyond Windows
[ https://issues.apache.org/jira/browse/FOP-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030873#comment-15030873 ] Andreas L. Delmelle commented on FOP-2540: -- EDIT - Note that the Macintosh/Roman cmap is currently processed as if it were a "symbol" cmap. This still needs to be revisited, I think. I have only done it that way now, since otherwise, the Macintosh/Roman cmap in the "Symbol" font would be processed before the Unicode/Unicode 2.0 cmap (i.e. the former appears before the latter in the font file), which would then leave the actual symbol codepoints unmapped... :( > Enhance TTF/OTF support beyond Windows > -- > > Key: FOP-2540 > URL: https://issues.apache.org/jira/browse/FOP-2540 > Project: FOP > Issue Type: Improvement > Components: font/opentype >Affects Versions: 2.0 > Environment: OS X >Reporter: Andreas L. Delmelle >Assignee: Andreas L. Delmelle >Priority: Minor > Attachments: FOP-2540.patch, test_osx_fonts_after_1.log, > test_osx_fonts_before.log > > > Currently, cmap tables in TTF/OTF are only supported for Platform ID = 3, > i.e. MS Windows. There is no support for Platform ID = 0, i.e. basic Unicode, > or 1, i.e. Macintosh. > This makes quite some system fonts bundled with OS X supposedly unusable. The > solution is fairly trivial (patch proposal will be attached shortly), > provided the cmap table format in the font is already supported. FOP > currently only has support for cmap format 4 (segment to delta mapping), but > this seems to suffice for most of the Unicode cmaps as well. > See also FOP-2539, which triggered me to investigate this closer. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
