Mozilla bug #327522 - fonts scaled up over 16pt on mac
had nonsensical extents. The scaling was being done using
the font matrix, it turns out this does not work for 16x
scaling and up. This patch switches back to using the
font size to scale fonts, with emboldening and condensing
effects applied separately using the font matrix.
- Add a to_unicode array to the scaled_font_subsets
for mapping glyphs to unicode characters
- Add a function to the TrueType subsetting for
performing a reverse cmap for mapping glyph indices
to unicode characters.
- Add a new scaled font backend function for mapping
glyph indices to unicode characters. Provide FreeType
and Win32 implementations of the font backend mapping
function.
- Modify the PDF backend to embed ToUnicode streams
into each font. The unicode mapping is obtained by
first trying the reverse cmap. If this fails the font
backend mapping function is called.
We recently added locking to cairo_scaled_font_glyph_extents and
to _cairo_surface_show_glyphs, but we had neglected the third
separate entry point into scaled_font code that does cache-using
glyph lookups, namely: _cairo_scaled_font_text_to_glyphs.
These three separate functions are plainly visible in the
implementation of cairo_show_text.
It seemed like a good idea to avoid holding the lock over the call
into the backend. But the procedure in place was quite broken:
LOCK
Fail to find font in hash table
UNLOCK
Create font
LOCK
Insert font into hash table
UNLOCK
since while we're busy creating the font and unlocked, another thread
can insert the font. Our paranoid hash table implementation noted
the problem quite readily.
This patch simply removes the internal UNLOCK/LOCK to hold the mutex
over the whole procedure.
With 50 iterations I'm seeing the following assertion failure:
cairo-hash.c:477: _cairo_hash_table_insert: Assertion `NOT_REACHED' failed.
Thanks to Jan Slupski <jslupski@juljas.net> for pointing out this bug.
A cairo_scaled_font_t can be implicitly shared among multiple threads
as the same cairo_scaled_font_t can be returned from different calls
to cairo_scaled_font_create. To retain the illusion that these
different calls produce distinct objects, cairo must internally lock
access when modifying them.
Each glyph in the scaled font is represented by a cairo_surface_t
which is used when rendering the glyph. Instead of attempting to push
fine-grained locking of these surfaces down to the backend rendering
functions, a simple per-cairo_scaled_font_t lock has been introduced
which protects the entire rendering path against re-entrancy.
Some care was required to ensure that existing re-entrancy was handled
appropriately; these cases are in the wrapping surfaces
(cairo-paginated, test-meta and test-paginated).
Thanks to Vladimir Vukicev and Peter Weilbacher for testing/providing
the mutex definitions for win32 and os2 (respectively).
Previously, with the magic in _cairo_scaled_font_reference(),
cairo_scaled_font_create() was releasing its lock just before
calling into reference() which would re-acquire the lock.
That left a window open during which a font we just discovered
in the holdovers table could be destroyed before we had a chance
to give it its initial reference back.
As in the previous commit with the backend->scaled_font_create
function, we also don't want to hold the lock when calling into
the backend's fini function.
Calling cairo_surface_finish from cairo_surface_destroy was
triggering an error due to finish being called twice. The
error was usually hidden as the surface would still eventually
be destroyed. But it did clutter things up quite badly if a
user was trying to break on _cairo_error to track down a
problem.
Thanks again to Stuart Parmenter <stuartp@gmail.com>
for pointing out the problem.
Current code for subsetting CFF fonts does not write charset information
into it. According to spec this means that font have ISOAdobe charset.
This charset contains only 228 names (excluding .notdef). This is not
enough for subfonts with 256 glyphs and causes bugs when viewing
generated PDFs.
Rotation and other transformations would cause extents to be
computed which were outside the bounds of the surface to be
cloned, (and for non repeating patterns). Now we simply
restrict the computed extents to the surface extents.
This fixes the xlib failure of the recent rotate-image-surface-paint
test, (the apparently distinct ps failure remains).
This test exercises a clone_similar extents bug noticed by
Benjamin Otte. As expected, the xlib backend fails due to
that bug, (and interestingly, the ps backend is showing a
failure as well).
PDF backend sets /LastChar value in Type1C font dictionary incorrectly.
acroread then complains about incorrect /Widths in font.
The last char is numchars - 1, since it's zero-based.
