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.