| Age | Commit message (Collapse) | Author |
|---|
|
Adobe Reader and Microsoft XPS viewer differ in their handling of
non-empty dashed strokes where the phase is 0: Adobe Reader considers
these to be faulty and omits them while Microsoft XPS Viewer renders
them the same as an empty dash (i.e. solid).
This patch makes Fitz no longer render such strokes and ensures that
MuXPS never emits them so that the desired behavior results (this is
the easier implementation since XPS rendering code renders stroked
paths in a single location whereas PDF rendering does it all over the
place).
See https://code.google.com/p/sumatrapdf/issues/detail?id=2339 for a
testcase.
|
|
If we perform a linejoin that ends up being over an impossibly small
distance, we can get a rendering error. This is caused by trying to
calculate scale = linewidth/sqrtf(len), where len < FLT_EPSILON.
Avoid this by rearranging the code slightly - no extra calculations
required.
Also given that sn == bn at all times within the stroking code, just
remove bn.
Credit for spotting this problem goes to Simon for tracking the
problem with rounding_artifact_due_to_closepath.pdf. My fix just
fixes the problem at a lower level than his does.
|
|
The bug fix added in the previous commit fails to work in this
case (hang-9527.pdf) because the matrix is not invertible and
hence the clipping rectangle ends up infinite. Spot this case
here and return early.
|
|
The first file of this bug (hang-66.pdf) hangs while stroking a
VERY long line segment; so long that 'used' is sufficinetly large
that:
used += dash_segment_len
doesn't result in a change in the value of used. The fix is
to clip strokes to the edge of the gel's clip area, meaning
that this should never occur.
|
|
|
|
|
|
|
