Adds some state, 'dash_starts_on', to keep track of whether a dashed path
starts with dash_on or not. This fixes the 'leaky-dash' bug (#4863) and
some other degenerate cases. The new version is, in my opinion,
considerably cleaner and more understandable than the old code.
Finally, the rewrite changes the behaviour of dashing to add degenerate
caps around corners that start at the same place as a dash begins. This
matches the behaviour seen in acroread.
This rewrite is based on an initial rewrite done by Jeff Smith.
has_initial_sub_path more accurately describes the condition we want to
track. This flag is used to indicate when an initial sub_path needs capping
but has no associated slope and thus no associated faces.
Commit 05ff2c77da contained
a fix for the acroread printing problem. However this
patch caused a problem for the Mac Preview PDF viewer.
http://lists.freedesktop.org/archives/cairo/2007-February/009615.html
This patch fixes the Mac Preview problem. The patch
- Adds a platform 3, encoding 0 cmap table
- Adds a post table that maps the glyph names in the
PDF truetype font dictionary (/g0 /g1 /g2 ...)
to glyph indices in the font.
We use a small cache of size 16 for surfaces created for solid patterns.
This mainly helps with the X backends where we don't have to create a
pattern for every operation, so we save a lot on X traffic. Xft uses a
similar cache, so cairo's text rendering traffic with the xlib backend
now completely matches that of Xft.
The cache uses an static index variable, which itself acts like a cache of
size 1, remembering the most recently used solid pattern. So repeated
lookups for the same pattern hit immediately. If that fails, the cache is
searched linearly, and if that fails too, a new surface is created and a
random member of the cache is evicted.
Only surfaces that are "compatible" are used. The definition of compatible
is backend specific. For the xlib backend, it means that the two surfaces
are allocated on the same display. Implementations for compatibility are
provided for all backends that it makes sense.
This was inadvertently changed as part of fdffde8b9e
With the Boolean, pango-using programs that locked the same
unscaled_font multiple times would crash with a message such as:
cairo-ft-font.c:569: _cairo_ft_unscaled_font_unlock_face: Assertion `unscaled->is_locked' failed.
This fixes a regression introduced with commit:
25a370d799
This was showing up as a failure of the bitmap-font test case
with the ps, pdf, and svg backends.
Since the last time these makefiles were last updated some new source
files have been added and one renamed. In addition, a "clean" rule
needed to be added to the pixman makefile. And the "clean" rule in the
main cairo makefile wasn't working properly for me.
The reference count of cairo_font_face_t is rather intimately tied,
(for toy font faces), with the cairo_font_face_hash_table, so we
expand the existing cairo_toy_font_face_hash_table_mutex to cover
the manipulation of font_face->ref_count as well.
This commit eliminates an assertion failure that is (occasionally)
exposed by the pthread-show-text test case:
lt-pthread-show-text: cairo-hash.c:196: _cairo_hash_table_destroy: Assertion `hash_table->live_entries == 0' failed.
Previously we just had an integer counter here, but that is not
sufficient as multiple cairo_scaled_font_t objects, (which are
implicitly shared through the font caches), can reference the
same cairo_ft_unscaled_font_t so real locking is needed here.
This commit eliminates an assertion failure exposed by the
pthread-show-text test case:
lt-pthread-show-text: cairo-ft-font.c:562: _cairo_ft_unscaled_font_unlock_face: Assertion `unscaled->lock > 0' failed.
We're planning to change the implementation of the public function,
(which will remove some locking safety), so use the safe, locked
_cairo_ft_unscaled_font_lock_face for internal use instead.
Don't use structure intitialization for assigning
structure values.
Add a new field to cff_charset_t to point to the sids
charset array instead of casting it into the data field.
The function _cairo_pdf_surface_write_fonts is the
original PDF TrueType font embedding function that was
disabled in commit f500cef19f
shortly before Type3 font support was added.
TrueType font embedding was later reintroduced as new code
making this function obsolete.
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.
