Inconsistent conditions for Type 3 font resources #128
Comments
|
What did you mean by "... further complicate the compatibility issue"? From my memory of past ISO discussions, I think your first bullet option is what is now generally preferred. And maybe a half-solution to the minor wording problem is that a cross-reference to Table 110 be added to the 2nd bullet in 7.8.3:
The second half of this sentence is a factual statement related to requirements in 9.6.4 so I don't see any issue. |
It will be impossible to maintain full compatibility since the previous text was inconsistent. Changing to "Required" is technically sub-optimal since it forces you to also emit an empty resource dictionary. What I meant is that an improved condition "required if non-empty" would deviate from the previous text even more.
I find it strange wording that "content streams shall include in a font dictionary", but that's not a technical issue. |
|
OK - thanks. I understand what you mean and I agree it is very unclear the "resource inheritance" locations used by Type3 CharProcs. Table 110 also states "If any glyph descriptions refer to named resources but this dictionary is absent, the names shall be looked up in the resource dictionary of the page on which the font is used." so there is a lot of contradiction between Table 110 and 7.8.3! We first need to decide what the desired behaviour is:
The third option needs to avoid accidental implications that an empty Type 3 Font dictionary Resources is always needed (but this would be valid syntax if an author wanted to stop the page Resources lookup). Comments? Opinions? Other options? |
Yes they can and yes they are used.
Not according to a well known implementation. It supports the model described next.
Yes, this is what a well known implementation does. (content stream then either font or page, depending) |
|
Based on feedback and discussion at PDF TWG, the current "shall" wording of the 2nd bullet of 7.8.3 "Resource dictionaries" is far too strict. But just replacing with "should" is also not correct, since the CharProcs content streams can have their own local Resource dictionary. So to solve this issue, proposal is to:
New wording for 7.8.3 2nd bullet is T.B.D. |
|
Actually the sentence "A list of the named resources, such as fonts and images, required by the glyph descriptions in this font (see 7.8.3, "Resource dictionaries")." in Table 110 also needs to be clarified, as the word "required" can easily be misinterpreted - it is not necessarily all Resources. |
|
I'm also now struggling to find where it is explicitly stated that content streams (in general) can all have a Resources entry... It seems to be that this is normally done in the Table that defines the type of dictionary, such as Form XObjects, Annotations, Shadings, etc. or by reference by stating that something is a Form XObject (for example). But AFAICT there is no equivalent for Type3 CharProcs. Table 110 CharProcs just says "A dictionary in which each key shall be a glyph name and the value associated with that key shall be a content stream that constructs and paints the glyph for that character." but there is no table of permitted keys for "general" content streams - you would expect that to be in clause 7.8.2. If Table 110 was altered to say "Form XObject" instead then it might resolve things... but does a Form XObject provide too much extra that is then even more confusing??? (e.g. StructParent, OC, etc). So if we only want to permit Resources entries on CharProc content streams what should we do??? Help requested! |
petervwyatt
added
help wanted
|
@petervwyatt: The bit you’re looking for is the 3rd bullet under 7.8.3:
Although that is a bit of a mixed message as to whether it applies to anything other than those three cases. Since pages and CharProcs are covered by the two previous bullets, I’m coming up short on other places it might be relevant. Oh dear; whenever you poke around in this stuff you find more loose ends. The discussion of needing to use the first Resources dictionary found in walking up the object tree, and not inheriting individual elements within a Resources dictionary separately, is specifically applied only to page objects (7.7.3.4). We’ll have to state that the same monolithic inheritance rules apply to CharProcs etc. I’d suggest adjusting the heading for 7.7.3.4 so it’s no longer page-specific and extending the text to cover all Resources inheritance, through Forms, fonts etc. While we’re on the subject, the statement of Resources inheritance through a chain of Form XObjects in the Resources row of Table 93 is a bit weak. If it’s PDF 1.1 or earlier then the requirements are clear. But if it’s PDF 1.2 or later, the form may be independent, and if so there is no inheritance of Resources ("the Resources dict shall contain …"). The implication is that the Form is not independent if it does not contain a Resources entry, but the text says nothing about what should happen then. I’ve always assumed that it should inherit from any containing Forms, and eventually up to the Page, but I can’t see that stated anywhere. Cover this in 7.7.3.4. If I’m being picky, the Resources row of Table 93 (Form XObjects) also says “In an independent form XObject, the resource dictionary of the form XObject […] shall contain all named resources used by the form XObject.” That pretty much implies that any resources used by child XObjects and T3 fonts also need to be in that Form Resources dictionary, which I’m pretty sure was not the intent. Perhaps “In an independent form XObject, the resource dictionary of the form XObject […] shall contain all named resources used directly by the form Xobject and its content stream.”? That may not be worth the effort, though. And why on earth would the Resources inheritance for a CharProc in a T3 font used inside a Form XObject nested inside a 2nd Form go: CharProc, font dictionary, page? Surely it should search through the chain of forms? I note that Resources in patterns explicitly do not inherit. Makes things much simpler 😊 |
|
PDF TWG would like to progress this during the next meeting... |
|
Putting this out as a straw man to argue over. I’m aware that some of this may change more wording than people are comfortable with, but it seemed a good starting point. These proposals are pretty much in order through the document rather than grouping by subject matter; I hope it’s still understandable. After discussion on this thread it seems that the consensus is converging on requiring a Resources dictionary in a Type 3 font. To do that, and to respond to Thomas’ comments on strange constructions, I propose replacing the 2nd bullet in 7.8.3 with the following, adopting wording based on the previous bullet (for resources on Page objects):
There’s also been a discussion around whether Resources is allowed in each CharProcs stream. I haven’t found anywhere in the current text that says what you’d do with it if it were present (as Peter says, any generic statements about Resources in arbitrary streams are pretty vague, especially if the list at the end of the 3rd bullet in 7.8.3 is taken as an exclusive list). Leonard says that a well-known implementation would use one, but that’s not sufficient reason to encourage people to add one. And the current state is a bit unclear, so I suggest adding this on the end of that 2nd bullet:
Inheritance of Resources dictionaries in Form XObjects in Table 93 is a bit unclear, so break it into two pieces: The 2nd para (starting “In a PDF whose version is 1.1”) is telling people how to make files against a 25-year old specification and does not seem appropriate in this standard. I suggest removing it, and replacing with a note along the lines of:
The 3rd para of the Resources Value cell in Table 93 is also confusing; it’s defining post PDF 1.1 behaviour by comparison with the obsolete v1.1 structures. I suggest deleting the entire paragraph. Bullet 3 in 7.8.3 states clearly that a Resources dictionary is required in a Form XObject (at least if the Form needs any resources). So I’d replace the current “Optional but strongly recommended” at the start of the cell, which contradicts 7.8.3, with Required. I could suggest "Required if the Form requires any resources" instead, but the overhead of needing to add an empty Resources dictionary is pretty low. Coming back to Type 3 fonts, this time in the Resources row of Table 110, replace “Optional but should be used” with “Usually required”. And then replace the last sentence of that cell with
Finally in that table cell, replace “required by the glyph descriptions” with “referenced by the glyph descriptions”. Delete the last sentence of bullet d in the list immediately below table 110. And finally, just to rock the boat on everything above: The fourth bullet in 7.8.3 is a bit problematic because it implicitly endorses converting a pre PDF 2.0 file to a PDF 2.0 file without bothering to enforce all of the PDF 2.0 rules. It basically says “I know we said Resources is required in a Form XObject or a Type 3 font, but you can break that rule if you prefer”. If we want to allow that because we believe that doing anything else would be too great a drag on PDF 2.0 adoption, then so be it, but we would need to go back to optional Resources in at least those two places. If we want to stay with making them clearly required then I suggest making the last bullet into a note, with appropriate tweaks to the wording. -end- |
petervwyatt
removed
help wanted
|
We discussed this in the call on 30 June 2022 and I was asked to come up with a concrete proposal. That discussion concluded that:
Those decisions contradict some of the earlier comments in this thread. So here goes: 7.8.3 Resource dictionaries
This is a clarification not a change because a resource referenced by an XObject that is itself referenced in a CharProcs stream is arguably not “used by a content stream in the CharProcs dictionary”. Probably best to leave the last bullet in that series as-is, or convert to a note. Worth discussing. Table 110
Replace with:
The required/optional statement is adapted from similar table entries elsewhere in the current text. Equivalent usage seems to consistently omit any sentence in the body of the description to repeat the conditions. This is arguably not a change as 7.8.4 already stated that “Content streams that define the glyph descriptions of a Type 3 font shall include a Resources entry in the Type 3 font dictionary specifying all the resources used by all the content streams in the CharProcs dictionary of a Type 3 font”. 9.6.4 Type 3 fonts
Add a new second sentence:
This is also a clarification, not a change because there has never been anything in the spec that describes a Resources entry in a CharProcs stream, while there are statements that resources required by a CharProcs stream shall be present in the Type 3 font or, in earlier versions, inherited from the page. |
I don't support this change - it will break some existing implementations that may indeed look for a Resources dictionary associated with this content stream. It would also make a CharProc stream different than every other content stream in a PDF. I see no benefit to that. |
|
PDF TWG discussed and proposed wording is not correct. Will try again... |
|
Capturing the discussion in the call on 21st July. In clause 7.8.3 (Resource dictionaries), amend the 2nd bullet as follows: Current:
Proposed:
In Table 110, amend the Value cell for Resources as follows: Current:
Proposed:
9.6.4 Type 3 fonts: In the lettered list below Table 110, amend item d) as follows: Current:
Proposed:
Note that the text in 7.8.3 is a file format requirement, and that in 9.6.4 is a processor requirement. |
|
PDF TWG agree with the changes as proposed. However it was noted that PDF/A (in clause 6.2.2) and PDF/X (in clause 6.7.1) both use the phrase "explicitly associated" w.r.t. to resources which needs improving regardless of the specific solution here. PDF/A and PDF/X wording applies more generally to all use of resources.
@lrosenthol - just tagging because you were away |
|
So I would actually want changes to the proposed text - I think the current proposals are too wordy and duplicative of material elsewhere in the spec that we should instead be referring to... |
|
Hi Leonard The last proposal could be replaced with this: 9.6.4 Type 3 fonts: In the lettered list below Table 110, amend item d) as follows: Current:
Proposed:
But note that the text in 7.8.3 is a file format requirement, and this in 9.6.4 is a processor requirement. So 7.8.3 explains where the Resources dictionary must be located. How that could be treated that as an instruction for a processor will be obvious to most developers, but is not strictly correct. If you meant something else, could you be more specific? In particular the proposal for 7.8.3 is much longer than the current text because our conclusion on the last couple of calls means that it needs to walk through a more complex sequence of potential locations for Resources. |
|
OK, one more attempt, with slightly fewer words. In clause 7.8.3 (Resource dictionaries), amend the 2nd bullet as follows: Current:
Proposed:
In Table 110, amend the Value cell for Resources as follows: Current:
Proposed:
9.6.4 Type 3 fonts: In the lettered list below Table 110, amend item d) as follows: Current:
Proposed:
Note that the text in 7.8.3 is a file format requirement, and that in 9.6.4 is a processor requirement. |
|
PDF TWG agree with the direction but some concerns over words. Will resolve through more discussion and approval via PDF TWG email. |
|
@petervwyatt , @lrosenthol : either of you care to fill in some more detail about your concerns here so we can move it forward on Thursday? |
|
Current wording in 9.6.4 uses "glyph description" whereas the proposed text uses slightly different and mixed terminology. For consistency and absolute clarity, I'd go with "glyph description content stream" everywhere and then be crystal clear as to whether a statement means only the glyph description content stream or the glyph description content stream and any referenced content streams. |
|
So beating up on a few more words: In clause 7.8.3 (Resource dictionaries), amend the 2nd bullet as follows: Current:
Proposed:
In Table 110, amend the Value cell for Resources as follows: Current:
Proposed:
9.6.4 Type 3 fonts: In the lettered list below Table 110, amend item d) as follows: Current:
Proposed:
Note that the text in 7.8.3 is a file format requirement, and that in 9.6.4 is a processor requirement. |
|
PDF TWG agree but some members wish to review wording more closely. |
PDF/A says "shall have an explicitly associated resources dictionary as described in ISO 32000-2:—, 7.8.3". "Explicitly associated" may already exclude the cases 3 and 4 where resources are inherited from pages. We could make that more clear if we change the order of lookups:
If there is no Resources dictionary explicitly associated with the CharProcs:
|
|
"If there is no Resources dictionary explicitly associated with the CharProcs:" would need to be "If there is no Resources dictionary explicitly associated with the CharProcs or the Type 3 font dictionary:" But isn't that unnecessary given that the first location that has a Resources dictionary should be used? |
|
My intention was to make it clear that the third and forth option are not consistent with PDF/A-4, if we want to keep the ISO32000-2 text clear of that it is indeed unnecessary. But I think the proposed way would be better than a note, because that note would tend to be a normative suggestion. |
|
I don't understand why Type 3 font Resources lookup is different than any other resources lookup in a non-page content stream. Shouldn't the same rules/path apply to annot appearances, for example? (module the actual Font dictionary). So why not just write this one and apply it in all cases? |
|
PDF TWG agree with the principle and suggestions of the comment of mine from Jan 4. |
|
Starting with Peter’s proposal from Jan 4th 2023, I suggest making the following changes. As proposed by Dietrich, adjust Peter’s proposal for the 2nd bullet in 7.8.3 (T3 font resources) to:
That will obviously require some care in getting the indenting right. I've replaced the 2nd level bullets with numbers to try to make it clearer. One of the primary sources of confusion appears to be the fourth bullet in 7.8.3, describing behaviour according to previous versions of PDF. That bullet does not describe the behaviour of PDF 2.0 writers, but appears to be setting requirements on PDF 2.0 readers for files that do not conform to PDF 2.0 (“resources … shall be inherited …”). I suggest replacing that bullet with a sightly re-phrased note. In rephrasing I’ve removed the reference to Type 3 fonts because the proposal for bullet 2 already describes the same behaviour. Bullet 3 explicitly lists annotation appearances and patterns. In PDF 2.0 (2020) patterns are required to have explicitly associated resources, and that’s true at least back to PDF 1.4. Appearance streams are explicitly form XObjects, so the requirement for forms to have explicitly associated resources also applies to them in PDF 2.0. In earlier versions the explicit description of annotation streams as form XObjects is still present, but of course forms did not have to have explicitly associated resources. As a result I’ve also added annotation appearance streams into the new note.
The following note will also need numbering. All other parts of Peter’s Jan 4th comment remain unchanged. |
|
Table 93 (Additional entries specific to a Type 1 form dictionary) Resources entry states the following which I think needs some tweaking now to align with @MPBailey's proposal above:
|
|
Further: 7.7.3.4 states that Linearized PDFs also don't inherit back up the page tree:
|
This is possibly an artifact of the "ISOification" process, but I suspect that that line was intended purely as a file format requirement, and not a processor instruction (@lrosenthol ?). If so, perhaps it should be reworded to make that more obvious. Maybe replacing the "they shall not be inherited..." bit with something like "Such documents shall not rely on inheritance to propagate attributes in the page tree" would work? |
|
There is a requirement in normative section F.3.10 that all inheritable attributes be pushed down to the leaf page objects precisely so that the Page tree is never required to display any page. So a conformant Linearized PDF will never have inheritable attributes. F.3.10 Other Objects (Part 9) |
|
Peter's comment on the Resources row in Table 93 is picking up on a loose end from a change made in the transition from Adobe PDF 1.7 to 32000-1 rather than directly associated with this issue, but ... I'd change the value cell along the lines of:
|
|
PDF TWG would like to:
|
|
PDF TWG agree to wording distributed via email. |
petervwyatt
added
ISO approved
Table 110 "Entries in a Type 3 font dictionary" states about the /Resources entry: "Optional but should be used".
On the other hand, 7.8.3 "Resource dictionaries" states in the second bulleted item
"Content streams that define the glyph descriptions of a Type 3 font shall include a Resources entry in the Type 3 font dictionary specifying all the resources used by all the content streams in the CharProcs dictionary of a Type 3 font."
Here "shall" contradicts "should" in Table 110.
Possible solutions (given inconsistent conditions it's hard to decide compatibility issues):
A better approach would be to require the Resources dictionary only if there actually are resources (i.e. don't require empty /Resources), but this would further complicate the compatibility issue.
A minor wording problem in 7.8.3 is that a content stream shall specify something in another location, which is weird phrasing for "if dictionary A is present, dictionary B shall contain X" (the content stream doesn't contain the resources, but actually the font does). Actually, since a Type 3 font without "Content streams that define the glyph descriptions" doesn't make sense this boils down to "/Resources is required in a Type 3 font dict", a statement which is redundant with the (corrected) entry in Table 110. The relevant information is that the Resources dictionary collects the resources in all CharProcs.
The text was updated successfully, but these errors were encountered: