Thank you for your comment and suggestion.

Keep in mind that CMap resources map code points, not sequences, to CIDs. In other words, mapping an IVS, such as <U+3402 U+E0101>, to a CID, which would be CID+13697, is a complete non-starter in the context of Unicode CMap resources. It is simply not possible. IVSes, along with SVSes, are handled via the UVS definition file, which is used to create the Format 14 'cmap' subtable.

The main purpose of the “ToUnicode” mapping resources, such as Adobe-Japan1-UCS2, is to derive content from embedded fonts whose glyphs are identified only by ROS and CIDs. In such resources, it is possible to map a CID to a sequence of code points.

Is there any thought to updating the UniJIS-UTF16-H CMap as well? At present if you want to display a glyph in PDF that would result from a variation selector (say CID 13697, from U+3402 U+E0101), the only way to do this is to use an Identity map in the PDF: there is no mapping to that CID in the cid2code.txt.

I realise the “shortest code first” approach makes integrating variation selectors into the UTF16-H/V CMap difficult. Is this under consideration, or should those of us creating PDFs just use the Identity encoding for Japanese text?

Thank you. Fixed now.

The Kozuka Mincho (小塚明朝) and Kozuka Gothic (小塚ゴシック) fonts that are bundled with Adobe Acrobat DC were updated to Version 7.001 early last month, to support Adobe-Japan1-7. I just checked the latest version of Adobe Acrobat DC, and I see that Version 6.014 of Kozuka Mincho Pr6N R and Kozuka Gothic Pr6N M are currently bundled. A forthcoming update should include the Version 7.001 fonts.

Vinay – JasperReports is using a VERY OLD (10+ years) version of an open source library against the wishes of the author of that library (see https://itextpdf.com/en/resources/faq/legal/itext-5-legacy/can-itext-217-itextsharp-416-or-earlier-be-used-commercially). It should come as no surprise that such an old version has bugs and produce invalid PDFs – as demonstrated in the thread that you linked to.
I would strongly suggest that you contact the folks at JasperReports and get them to update their PDF creation library.

While there are indeed Unihan considerations for U+4EE4 令, as exemplified by the Source Han typefaces that include separate JP (shared by KR), CN, and TW (shared by HK) glyphs, there are none when it is used as the first component ideograph of U+32FF SQUARE ERA NAME REIWA, because it is a character that is specific to Japan. Implementations are certainly free to design CN and TW forms of this two-ideograph square ligature, but it is completely unnecessary.