I'm working with a lot of third-party PDFs and since we are thinking about changing our rendering engine, I would like to compare different available engines. However, there are subtle differences in the rendering, so that I had to wonder, what do I have to compare those renderings against, is there any kind of reference renderer? Is it Adobe's Acrobat?
Yes, essentially every user expects every PDF renderer to match Adobe Acrobat.
Note though that the PDF specification does not describe rendering down to the pixel level, so some slight variations is expected and normal.
In particular Font hinting and aliasing are acceptable differences. And of course you can get into CMYK and how to best represent that on a RGB screen, so some variance can happen depending on the color profile selected.
A refrence to pdf informs that a pdf dictionary to defined a font resource needs to contain a property /Widhts giving this information:
(Required except for the standard 14 fonts; indirect reference
preferred) An array of ( LastChar − FirstChar + 1) widths, each
element being the glyph width for the character code that equals
FirstChar plus the array index. For character codes outside the range
FirstChar to LastChar , the value of MissingWidth from the
FontDescriptor entry for this font is used. The glyph widths are
measured in units in which 1000 units corresponds to 1 unit in text
space. These widths must be consistent with the actual widths given in
the font program. (See implementation note 61 in Appendix H.)
emphasis added.
What good is it to provide the widths again is they are obviously included in the font program?
Plainly: Can somebody confirm or reject wether the information one is supposed to provide here, the glyph width is blantantly redundant information, considering it is even mentioned to be contained in the font-program?
Or do some font programs inlcude glyphs without specifying their widths?
Is it because there are font programs that do not include the widths, or is this merely an execercise in patience, indented to complicate the generation of PDF files, hoping people then stick to Adobe software?
Are the /Widths entries required to test if a referenced font (being not embedded), is "correct" (i.e. the pdf viewer is supposed to check if the font-program wanted by the pdf, might be the one found on the platform, comparing the /Widths)?
The Widths array is documented as being present so that application programs can determine the metrics of glyphs without being required to decode a font. This might be of use (for example) when drawing a selection box around text, or highlighting text in some manner.
See pages 393 and 394 of the PDF 1.7 specification:
The width information for each glyph is stored both in the font
dictionary and in the font program itself. (The two sets of widths
must be identical; storing this information in the font dictionary,
although redundant, enables a consumer application to determine glyph positioning without having to look inside
the font program.)
I should also mention that there are many PDF producers which regard abusing the Widths array as a convenient way to alter the spacing of a font. Where the Widths of the Font array do not match the metrics of the glyphs in the font program, Acrobat uses the Widths array values (which is the implementation note in Appendix H referred to by the text you quoted). I also seem to recall that the latest version of the specification lifts the exception for the base 14 fonts, all fonts are supposed to have a /Widths array now.
We've got numerouus examples of PDF files where the metrics array do not match the Widths in the font program.
Note that the Preflight checker in Acrobat Pro, when checking for PDF/A compatibility, will throw an error if the Widths and metrics differ.
So while it is technically true that the /Widths array is redundant, because the same information can be retrieved from the font, it is convenient for some applications to have the informaiton in a more readily accessible form and if (as a PDF consumer) you hope to match the rendering from Acrobat, you need to use it.
This is how the .ttf font is rendered:
I have created this vector-only TrueType font using FontForge.
I want to use this font on applications which require vector-based glyphs, and do not support loading .ttf embedded bitmaps (which do not seem to have this problem).
On certain color-schemes this sub-pixel rendering that Windows does makes the font completely unreadable. This effect is present in most ttf fonts, but is much stronger on fonts with pixel-perfect edges like mine.
Does anybody know any programmable hinting tricks or font-settings that will allow the font to render pixel-perfectly instead of with this red/blue halo? I would like the font to work properly without OS modifications to disable ClearType or similar.
To clarify, this is a question about leveraging the TrueType Instruction Set, or changing a TrueType font-setting (not a System/Application setting) that I have may have neglected to set properly, to make the font render legibly (if possible).
Working Solution
Credit goes to Brian Nixon for posting the solution URL, and to Erik Olofsson for researching and posting the solution on his blog.
Erik Olofsson provides a solution that forces Windows font API to prioritize .ttf embedded bitmaps to be used with priority over glyphs when rendering.
The solution can be found in detail at http://www.electronicdissonance.com/2010/01/raster-fonts-in-visual-studio-2010.html
Solution Summary
Add 'Traditional Chinese' code page to the OS/2 Panpose table.
Use the 'ISO 106046-1' (Unicode, UCS-2) encoding.
Include glyphs for the following seemingly random Hiragana characters:
い - U+3044
う - U+3046
か - U+304B
ひ - U+3057
の - U+306E
ん - U+3093
This list is not a joke
On certain color-schemes this sub-pixel rendering that Windows does makes the font completely unreadable.
It sounds as if ClearType is not correctly calibrated.
"Pixel-perfect" display is possible only when the text color matches a color plane of the display. For black or grayscale text, that means a grayscale display (high-resolution and expensive digital monochrome displays are popular in the medical imaging field, for example).
Otherwise, you run into the fundamental fact that color components are physically separated on the display. The concept of ClearType is to adjust the image to compensate for the actual physical offset between color planes.
Printed media with high-precision registration is the closest you get to multiple color planes without any offset.
Now, it does still make sense to disable ClearType in some cases -- when the image is intended to be saved in a file rather than presented on the local display, disabling ClearType can produce results that are legible across a wider range of displays and also compress better. (But for best results, send vectors and let the end-user display compensate for its particular sub-pixel structure)
In GDI, control of ClearType is set via the LOGFONT structure that command text-drawing functions which font family, size, and attributes to use. In GDI+, use SetTextRenderingHint on a Graphics instance.
Because the use of ClearType is set by the application at the same time as size, weight, and other attributes, your font is subject to being requested both with and without. However, ClearType is not compatible with all fonts, by forcing incompatibility you will avoid ClearType for your font alone.
The LOGFONT documentation has the following remarks about ClearType:
The following situations do not support ClearType antialiasing:
Text is rendered on a printer.
Display set for 256 colors or less.
Text is rendered to a terminal server client.
The font is not a TrueType font or an OpenType font with TrueType outlines. For example, the following do not support ClearType antialiasing: Type 1 fonts, Postscript OpenType fonts without TrueType outlines, bitmap fonts, vector fonts, and device fonts.
The font has tuned embedded bitmaps, for any font sizes that contain the embedded bitmaps. For example, this occurs commonly in East Asian fonts.
In addition, the gasp table within the TTF format has several fields specified to influence ClearType usage.
Documentation at https://www.microsoft.com/typography/otspec/gasp.htm
and https://fontforge.github.io/fontinfo.html#gasp
And of course, make sure that the "optimized for ClearType" bit in the head table is not set.
I need to get the x/y, width/height, and page number of each individual character in a PDF, ideally as percentages.
Clearly, Ghost Script is able to do this as it wouldn't be possible to convert PDFs to raster images otherwise. Is there a simple way to get Ghostscript to give me this information or am I going to need to modify the source to hook into this functionality?
Glyphs are rendered to bitmaps (using FreeType) and stored in the glyph cache tagged with the font and matrix so that they can be uniquely identified. When text is rendered to the page the cache is consulted first and if a hit exists that bitmap is drawn at the current point. If not then the glyph is rendered and cached.
However, extremely large point sizes are left uncached, and rendered each time to avoid filling up or overflowing the cache.
So in order to retrieve this information using Ghostscript you would need to write a device which has a set of text methods. You would need to capture the bitmaps from the glyph in order to determine the width and height of the glyphs, and the current point would give you the position on the page. The output_page method would tell you that a page had completed, so you would need to track the page number yourself.
You could look at the txtwrite device to see how text is processed, and the epswrite device to see how to retrieve bitmaps, you'll need some combination of both.
Be aware that 'text' in a PDF file need not be text. What appears to be text can be bitmaps, or vectors. Text can be encoded in unusual ways, and there may be no way to retrieve Unicode or other identifiable information about the glyphs (again the txtwrite device shows how you might extract such information if possible).
Also, fonts are not always embedded in PDF files, in which case a substitute font is used, which would mess up your width/height information.
This is quite a big project.
Is there a library/tool which would list all colours used in a PDF document ?
I'm sure Acrobat itself would do this but I would like an alternative (ideally something that could be scripted).
So the idea is if you have a very simple PDF document with four colours in it the output might say :
RGB(100,0,0)
RGB(105,0,0)
CMYK(0,0,0,1)
CMYK(1,1,1,1)
You could explore the insides with pdfbox, but you would have to write some code to find and catalog all those colors.
Most PDF tools have access to this information but no api to access it. You could take any tool and add it in
Apago PDFspy generates an XML file containing all kinds of metadata extracted from PDF files. It reports color usage including spot colors.
We recently added a function called GetPageColorSpaces(0) to the Quick PDF Library - www.quickpdflibrary.com to retrieve much of the ColorSpace info used in the document.
Here is some sample output.
Resource,\"QuickPDFCS2eb0f578\",Separation,\"HKS 52 E\",DeviceCMYK,0.95,0,0.55,0
Resource,\"QuickPDFCSb7b05308\",Separation,\"Black\",DeviceCMYK,0,0,0,1
Resource,\"QuickPDFCSd9f10810\",Separation,\"Pantone 117 C\",DeviceCMYK,0,0.18,1,0.15
Resource,\"QuickPDFCS9314518c\",Separation,\"All\",DeviceCMYK,0,1,0,0.5
Resource,\"QuickPDFCS333d463d\",Separation,\"noplate\",DeviceCMYK,1,0,0,0
Resource,\"QuickPDFCSb41cafc4\",Separation,\"noprint\",DeviceCMYK,0,1,0,0
Resource,\"Cs10\",DeviceN,Black,Colorant,-1,-1,-1,-1
Resource,\"Cs10\",DeviceN,P1495,Colorant,-1,-1,-1,-1
Resource,\"Cs10\",DeviceN,CalRGB,Colorant,-1,-1,-1,-1
Resource,\"Cs10\",Separation,\"P1495\",DeviceCMYK,0,0.31,0.69,0
XObject,\"R29\",Image,,DeviceRGB,-1,-1,-1,-1
Disclaimer: I work at Atalasoft.
Our product, DotImage with the PDF Reader add-on, can do this. The easiest way is to rasterize the page and then just use any of our image analysis tools to get the colors.
This example shows how to do it if you want to group similar colors -- the deployed example will only work for PNG and JPEG, but if you download the code, it's trivial to include the add-on and get PDF as well (let me know if you need help)
Source here:
http://www.atalasoft.com/cs/blogs/31appsin31days/archive/2008/05/30/color-scheme-generator.aspx
Run it here:
http://www.atalasoft.com/31apps/ColorSchemeGenerator
If you are working with specific and simple PDF documents from a constrained source then you may be able to find the colors by reading through the content stream. However this cannot be a generic solution.
For example PDF documents can contain gradients or transparency. If your document contains this type of construct then you are likely to end up with a wide range of colors rather than a specific set.
Similarly many PDF documents contain bitmapped images. Given that these will need to be interpolated to be displayed at different resolutions, the set of colors in a displayed PDF may be bigger or different to (though obviously broadly similar to) the embedded bitmap.
Similarly many PDF documents contain constructs in multiple color spaces that are rendered into different color spaces. For example a PDF might contain a DeviceRGB bitmap, a line in an ICC based CMYK color and a Lab based rectangle. The displayed version might be in sRGB for display or CMYK for print. Each of these will influence the precise set of colors.
So the only 100% valid answer is going to be related to a particular render of a PDF at a particular resolution to a particular color space. From the resultant bitmap you can determine the colors that have been used.
There are a variety of PDF libraries that will do this type of render including DotImage (referenced in another answer) and ABCpdf .NET (on which I work).