[
https://issues.apache.org/jira/browse/PDFBOX-2648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14702725#comment-14702725
]
Petras edited comment on PDFBOX-2648 at 8/19/15 8:59 AM:
---------------------------------------------------------
As stated in PDF/A-1 specification:
{quote}
For all *CIDFont* subsets referenced within a conforming file, the font
descriptor dictionary shall include a
*CIDSet* stream identifying which CIDs are present in the embedded *CIDFont*
file.
{quote}
PDF/A-2 (and PDF/A-3) makes *CIDSet* optional but specifies the requirement for
*CIDSet* more detailed:
{quote}
If the *FontDescriptor* dictionary of an embedded CID font contains a *CIDSet*
stream, then it shall identify all CIDs which are present in the font program,
regardless of whether a CID in the font is referenced or used by the PDF or not.
{quote}
Anyway, for both requirements it is not clear how to correctly generate
*CIDSet* or verify it, when TrueType font program is used as part of a CIDFont
(i.e. of *CIDFontType2* subtype). There is no such thing as CID in TrueType,
which has GIDs. Therefore in PDF for glyph selection *CIDToGIDMap* must be
used. That means it is impossible to verify that *CIDSet* does identify all
CIDs, that are present in font program, as CIDs are not present in TrueType
font at all. Should I understood this requirement as:
* *CIDSet* shall identify all CIDs that are mapped in *CIDToGIDMap*? If so,
then in case of *Identity* value, *CIDSet* should identify all glyph indexes
which are present in TrueType font, shouldn't it?
Maybe I'm missing something?
I asked this question in Adobe Community forum, no replies received yet. What
is your opinion, how Preflight should validate *CIDSet* for TrueType font
program?
was (Author: abyss):
As stated in PDF/A-1 specification:
{quote}
For all *CIDFont* subsets referenced within a conforming file, the font
descriptor dictionary shall include a
*CIDSet* stream identifying which CIDs are present in the embedded *CIDFont*
file.
{quote}
PDF/A-2 (and PDF/A-3) makes *CIDSet* optional but specifies the requirement for
*CIDSet* more detailed:
{quote}
If the *FontDescriptor* dictionary of an embedded CID font contains a *CIDSet*
stream, then it shall identify all CIDs which are present in the font program,
regardless of whether a CID in the font is referenced or used by the PDF or not.
{quote}
Anyway, for both requirements it is not clear how to correctly generate CIDSet
or verify it, when TrueType font program is used as part of a CIDFont (of
*CIDFontType2* subtype). There is no such thing as CID in TrueType, which has
GIDs. Therefore in PDF for glyph selection *CIDToGIDMap* must be used. That
means it is impossible to verify that *CIDSet* does identify all CIDs, that are
present in font program, as CIDs are not present in TrueType font at all.
Should I understood this requirement as:
* CIDSet shall identify all CIDs that are mapped in CIDToGIDMap? If so, then in
case of *Identity* value, *CIDSet* should identify all glyph indexes which are
present in TrueType font, shouldn't it?
Maybe I'm missing something?
I asked this question in Adobe Community forum, no replies received yet. What
is your opinion, how Preflight should validate CIDSet for TrueType font program?
> Preflight does not check CIDSet contents
> ----------------------------------------
>
> Key: PDFBOX-2648
> URL: https://issues.apache.org/jira/browse/PDFBOX-2648
> Project: PDFBox
> Issue Type: Bug
> Components: Preflight
> Affects Versions: 2.0.0
> Reporter: Tilman Hausherr
> Fix For: 2.1.0
>
>
> As correctly observed by [~zuki_ebetsu]:
> {quote}preflight seems to check only the presence of the stream{quote}
> So we need to check the contents too, somehow. At the very least, that would
> be the length. Next thing would be to verify that the bits correspond to the
> CIDs that are present.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
