In order to avoid re-rasterising a glyph that is pending an
XRenderFreeGlyph, we first scan all glyphsets and their arrays of
pending_free_glyphs for a matching glyph. The additional cost of
scanning the extra arrays should be negligble as most fonts will only
have the single array (which we would scan anyway) but we potentially
save an expensive rasterisation and short-lived image surface.
(As suggested by Behdad Esfahbod.)
Enlarge the embedded arrays of edges and points for cairo_polygon_t and
cairo_spline_t respectively, such that the frequent allocations are
eliminated whilst running a firefox3 benchmark.
First try to allocate the vertices using an on-stack array, otherwise, if
we need more vertices than can be accomodated, fallback to using a heap
array.
That is, instead of uniformly spreading the colors at 0/4, 1/4, 2/4, 3/4, 4/4
intensities, we do 0/7, 1.5/7, 3.5/7, 5.5/7, 7/7 now. Those better
approximate the 0/7..7/7 of the rgb333 space that we first convert to.
The PDF output no longer requires a PDF specific reference image. The
lastest poppler from git is required to get the fix for a bug in Type
3 font rendering.
show_glyphs inside a Type 3 font currently results in a fallback
image. Some refactoring is required before font subsets can be created
while emitting all the font subsets.
Based on patch from Stuart Parmenter. Now one can use
cairo_ft_font_face_create_for_pattern() to create cairo-ft font
faces using provided FT_Face but also requesting advanced
options like emboldening and hinting.
Rewrite the PDF operators show_glyphs() function to make it more
maintainable and better optimized.
The changes include:
- Use a separate function to output each text operator and update the
internal state.
- Store glyphs in a buffer until they can be written out as one
string. This reduces the complexity of the code for emitting glyph
strings and significantly optimizes the output size as glyphs from
multiple calls to show_glyphs() can be accumulated and written in one
string.
- The code now better handles rotated text. Previously, using rotated
text resulted in the text matrix emitted for every glyph. Now rotated
text can be emitted as strings in the some way as non rotated
text. This is particulary useful for printing in landscape mode where
all text on the page is rotated.
A text object is a series of text operations enclosed in a 'BT'/'ET'
pair.
After a call to _cairo_pdf_operators_show_glyphs() the closing 'ET'
will not be emitted. This allows subsequent calls to show_glyphs() to
emit text into the same text object. A call to any other operator or
_cairo_pdf_operators_flush() will close the text object.
The optimizations planned for pdf-operators will mean that it will no
longer emit complete operations on each call to
fill/stroke/show_glyphs. For example a call to _show_glyphs() may not
finish the text operation to allow a subsequent call to _show_glyphs()
to be merged into the same text object.
A flush function is required to force pdf_operators to complete the
current operation before the pdf surface can emit any pdf operators.
Some Type 1 fonts have some PostScript code at the start of the font
that checks if the font is already cached in the printer (based on the
font UniqueID key). This breaks our subsetted font as it is not the
same as the original font.
Checking for and removing a random blob of PostScript is difficult so
this patch takes the simpler approach of searching for the PS code
that checks if the UniqueID dictionary entry exists
ie
/UniqueID known
this code leaves the value "true" or "false" on the PS interpreter
stack depending on whether the "UniqueID" key exists.
Then the patch inserts the PS code " pop false " after the above code
to remove the old result and place "false" on the stack to make it
appear that UniqueID does not exist.
This approach should be able to handle any type of PostScript code
that attempts to do something with the UniqueID value in the font
dictionary.
This ensures that PS/PDF output is always the same for the same cairo
input. Previously the order of the embedded fonts depended on the hash
key of the fonts which depended on the memory location of fonts.
In the eexec encryption used in Type 1 fonts, the first four bytes of
ciphertext must not start with a white space character or contain an
ASCII Hex character. Some fonts do not comply with this
restriction. This may cause problems for some PDF consumers.
Fix this by overwriting the four random bytes at the start of the
decrypted cleartext with spaces. When re-encrypted the first four
bytes of ciphertext will always be 0xf0, 0x83, 0xef, 0x00 which
complies with the restrictions.
