Planned for Future Release

We understand the use case for providing access to alternate characters in a font when they are not mapped to unique Unicode values. We’ve implemented support for CMaps which provide that capability for some of the fonts and publish work streams today. However, we have recently confirmed that we cannot provide support for CMaps with OpenType fonts when Direct to PDF is being used. There is no simple resolution for this specific use case today.

Ideally, we want to provide one alternate character mapping mechanism that will handle all fonts. Based on what we have learned while analyzing this use case that may not be possible and we may need to add a separate processing path for OpenType fonts. In either case, the research, analysis and subsequent development and QA will require a large effort that needs to be scheduled into the product roadmap.

We are now tracking this as XPP product backlog ID: XPP 7878. We have currently targeted XPP 9.7 for Early Access this fall, with general availability targeted for early next year. While we do expect to perform some initial research and analysis during this timeframe, we will not be able to complete this backlog item before we release XPP 9.7 so it is being targeted for a future release and we will keep this community posted.

April 2024 update: XPP 9.7 has been released and we are currently working on the design and determining the level of effort for implementing this.

Method for accessing characters in an OTF font not bound to a Unicode value

XPP is able to access any glyph in an OTF font that is bound to a Unicode value.

However important character sets that may be included in a font such as Old Style Figures, Small caps or (tabular/lining/proportional) figures that do not have a corresponding Unicode value in a font cannot be access by XPP.

It would be very useful to be able to selectively utilize all the glyphs that are included in OTF fonts.

  • Having the ability to tell XPP to automatically switch to tabular alignment figures if I'm a non-sub/superscripted figure in a table.
  • Switch to Old Style Figures if a certain pagination style table is in effect.
Thomas Mangan
  • in reply to Thomas Mangan
    I would not expect to be able to mix characters on import. I would be choosing characters from the .tf items OR the .alt items - not both. Anything from the .alt characters, I would have to revert back to the manual method of adding characters (cmap / PTS).

  • Further justification / detail

    Font vendors/foundries are starting to refuse to create alternate versions of their fonts that support tabular alignment out of the box. Most recently Hoefler & Co has said they will no longer be issuing any "TF" versions of their typefaces. The result is a manual editing of cmap files and PTS specs that can be prone to error. Based on my most recent experience doing this (30+ individual fonts), I would like to suggest a modification to the font installation process (please see Case No. 00570922 for more detail).

    Possible implementation / idea

    As part of the FontCopy process, I would like a file containing the character suffixes "seen" in the font file being processed. Based on suffixes contained in the generated file, I would like the option to select which suffix to use during the BuildFast step and which characters to include/exclude. The following scenario may help:

    During the FontCopy process, the font is seen to include characters with the following suffixes. These suffixes are stored somewhere that can be accessed in the BuildFast (or next logical installation step):

    .alt - alternate glyph/design

    .tf - tabular lining characters

    .tab - tabular lining characters (another suffix for the same thing as .tf)

    During the BuildFast (or next logical installation step), an option to use characters with one of the suffixes contained in the font is presented. If the .tf suffix is selected, I would be prompted to choose which characters with the .tf extension are used and assigned to the corresponding Unicode address. Once the characters have been selected, the cmap file would be updated and the character widths that correspond to my .tf selections would be correctly entered into the PTS spec prior to the FAST generation.

    The ability to select specific characters is important

    I understand why an all or nothing approach would be preferred over allowing a user to select specific characters because then the development team is dealing with an absolute rule "If the .tf suffix exists, then I'll assign it the Unicode address".

    However in practice that doesn't work. The tabular symbols for percent signs, commas, periods etc... are not necessarily glyphs you want used.

    For this functionality to be useful, the characters "found" with the .tf would need to be offered as an option for selection. It's an extra step, but that's what will make this functionality useful.

  • support for ligatures, old style figures, small caps, etc has been asked several times over time in the wish list session.

    So I fully support this request