C++ SDK - bad /BBox for any TT fonts in appearance stream even though they display fine

Report · Feb 27, 2023

I am using teh STAMPR sample to create a custom annotation type. It works as far as displaying it goes, but the first time it displays a True Type character, i get the pop up that says the font has a bad /BBox. I have tried diffrent fonts and they all getit. i use the font elsewhere in a textrun and it doesn't get the error.

I modified the Cos generation in teh sample as shown below the commented out parts were where I tried a couple of things - one that I found suggested as it culd force a defaut and the other just being a large BBox that no character should ever exceed. Currently not adding the entry at all as the doc say it will be determined by using information in the font.

After I get the message box once, it doesn't show again until I close and reopen the file.

And finally, there is one symptom that concerns me the most and makes me wonder if it might be a problem with Acrobat. If I use two different fonts, it will only complain about teh first charcter of the first font. It will not report a problem with the second font. This is true in either order; whichever font I use first will get an error reported once only and teh other font will not get an error reported.

Creating the font entry:

// Add Font resource to Resources dictionary.
fontResObj = CosNewDict(cdoc, true, 1L);
fontResObj2 = CosNewDict(cdoc, true, 5L);
cObj = CosNewNameFromString(cdoc, false, "Font");
CosDictPutKeyString(fontResObj2, "Type", cObj);
cObj = CosNewNameFromString(cdoc, false, "TrueType");
CosDictPutKeyString(fontResObj2, "Subtype", cObj);
//cObj = CosNewNameFromString(cdoc, false, CurrentTickItem->FontName.c_str());
//CosDictPutKeyString(fontResObj2, "Name", cObj);
cObj = CosNewNameFromString(cdoc, false, sFontName);
CosDictPutKeyString(fontResObj2, "BaseFont", cObj);
//cBBoxObj = CosNewArray(cdoc, false, 4L);
//CosArrayInsert(cBBoxObj, 0L, CosNewInteger(cdoc, false, 0L)); // left
//CosArrayInsert(cBBoxObj, 1L, CosNewInteger(cdoc, false, 0L)); // top
//CosArrayInsert(cBBoxObj, 2L, CosNewInteger(cdoc, false, 0L)); // right
//CosArrayInsert(cBBoxObj, 3L, CosNewInteger(cdoc, false, 0L)); // bottom
//CosDictPutKeyString(fontResObj2, "FontBBox", cBBoxObj);
//cObj = CosNewNameFromString(cdoc, false, "[-8 -280 995 855]");
//CosDictPutKeyString(fontResObj2, "FontBBox", cObj);

CosDictPutKeyString(fontResObj, sFontName, fontResObj2);
CosDictPutKeyString(cResObj, "Font", fontResObj);

Report · Feb 27, 2023

By my reading of the PDF spec, and my estimate of what your code does, it is not a compliant font object (even if it sometimes works) because

- FontBBox belongs in a FontDescriptor, not a Font Dictionary (except for type 3 fonts)

- FontBBox is required

Furthermore, //cObj = CosNewNameFromString(cdoc, false, "[-8 -280 995 855]"); if you used it, is not how you create a FontBBox. It must be an array object.

- FontDescriptor is required (except for the base 14 fonts)

Report · Feb 27, 2023

In the PDF spec, there is an example of a PDF entry for a TrueType font. It does not have a /BBox. BTW, it doesn't "sometimes work". It always works - 100% of the time the character shows using the requested font. Acrobat pops up teh message box once and only once, for the first occurence of an appearance stream using a TrueType font. It does not pop up for subsequent appearance streams even if they use a different TrueType font

Example 5.8 1

7 0 obj

<< /Type /Font

/Subtype /TrueType

/BaseFont /NewYork,Bold

/FirstChar 0

/LastChar 255

/Widths 23 0 R

/FontDescriptor 7 0 R

/Encoding /MacRomanEncoding >> endobj

23 0 obj [0333 333 333 333 333 333 333 0 333 333 333 333 333 333 333 333 333

…Omitted data…

803 790 803 780 780 780 340 636 636 636 636 636 636 636 636 636 636 ] endobj

Report · Feb 27, 2023

I will try the font decriptor. I hadn't noticed the working STAMPR sample left that out.

Report · Feb 27, 2023

Addin font descriptor stopped it from displaying the error. Unfortunately, it also stopped it from working; it no longer displays.

cObj = CosNewNameFromString(cdoc, false, "7 0 R");
CosDictPutKeyString(fontResObj2, "FontDescriptor", cObj);

Report · Feb 27, 2023

You need to stop doing things like this.

cObj = CosNewNameFromString(cdoc, false, "7 0 R");

A font descriptor must be a direct or indirect reference to a dictionary object. This is a name object, nothing else.

You cannot copy and paste sections of PDF syntax like "7 0 R" or "[0 0 100 100]" into CosNewName (or CosNewString) and use it instead of the correct structures.

Report · Feb 27, 2023

I was trying to generate what was in the PDF spec example. Using a string entry name and a string object should generate the line as shown, shouldn't it? Like the Basefont and the font name does. In one of the samples, I found the bracket syntax as an alternate way to provide array data, like is used in the referenced widths array - the light bulb just came on about that. I will have to add something to generate that for my fonts.

Report · Feb 27, 2023

No, absolutely not. This is not how to use the API.

The PDF syntax (with [arrays] and << dictionaries >> and so on) is how the PDF is saved to disk.

The API is dealing with the in-memory representation of the objects.

To create the equivalent of [1 2 3] - which is four objects in all - you need one call to CosNewArray, three calls to CosNewInteger, and three calls to CosArrayPut.

To create the equivalent of << /A 3 /B (string) >> you need one call to CosNewDict, one call to CosNewInteger, one call to CosNewString, and two calls to CosDictPut - just as you find in the example you have been working from.

To create the equivalent of 7 0 R you need a CosObj containing an indirect object reference to the object which happens to be object 7, and which you cannot reference by number, it has to already exist in the PDF, or you create it with CosNew<type>

The PDF reference tells you the required keys for a FontDescriptor dictionay; you have to set them each, one by one.

Report · Feb 27, 2023

It was in a different working sample where I found the syntax of just using the string that will eventually be generated in the stream. In the case of an array, it is a left bracket, the members of the array space delimited and then the right bracket. Kind of makes sense; it is on reading it in that the code cares about specific key names and interprets the string to construct the expected arrays and or structures.

I can switch to generating the same strings a different way, but I really don't expect a different result.

Report · Feb 27, 2023

It is a pity if Adobe included something so profoundly wrong and misleading in a sample. I can see why you would do it but you need to stop. CosNewName makes a name object only, the contents are not parsed.

This will not generate an error at the time, and the object, since it was expected to be an array, will be treated as missing.

To verify this isn't an undocumented trick, I tested this code

CosDictPut ( CosDocGetRoot(PDDocGetCosDoc(pddoc)) , ASAtomFromString("ArrayTest") ,

CosNewName ( PDDocGetCosDoc(pddoc) , false , ASAtomFromString("[1 2 3]") ) ) ;

This creates a name object called "[1 2 3]" which is legal but unusual. It is written to the PDF using escapes so it does not get parsed as an array. In the test PDF I find:

<</ArrayTest/#5B1#202#203#5D ...

Report · Mar 01, 2023

Trying a different route, I was going to generate teh CosObj from either a PDEFont or PDSysFont, as I have code that generates them with the same font elsewhere in the plugin and they are printed to the page without any error. But I don't see any function to get the CosObj from either one. Is there something I am overlooking? Nearly every object I have dealt with has some function that does that.

Report · Mar 02, 2023

nvm - I was somehonw overlooking the function for that in the docs