Age | Commit message (Collapse) | Author |
|
|
|
|
|
Several things irk me about passing values as const pointers:
* They can be NULL, which is not a valid value.
* They require explicit temporary variables for storage.
* They don't compose easily in a legible manner, requiring
weird pointer passing semantics where the variable being assigned
is hidden as an argument in the innermost function call.
* We can't change the value through the pointer, requiring yet more
local variables to hold copies of the input value.
In the device interface where we pass a matrix to a function, we often
find ourselves making a local copy of the matrix so we can concatenate
other transforms to it. This copying is a lot of unnecessary busywork
that I hope to eventually avoid by laying the groundwork with this
commit.
This is a rather large API change, so I apologize for the inconvenience,
but I hope the end result and gain in legibility will be worth the pain.
|
|
When rendering dash lines with a dash pattern that starts with
a length of zero, the first dash should be of zero length. If
we are using round caps, this should actually show up!
|
|
If the move due to a closepath is infinitessimal, fz_stroke_lineto
skips it as it cannot accurately figure out what the direction is.
It appears we have had some code in fz_stroke_closepath to cope
with exactly this case, but it does the wrong thing. This dates
back all the way to the initial import of the code, so presumably
it worked at some point, and stopped working somewhere along the
line.
|
|
When stroking paths if we meet segments of 0 length, we can't
determine a direction, thus start/end caps are omitted. Line
widths are irrelevant, and we thus render nothing.
(Note that moves on their own do NOT count as a line segment).
The exception to this is where we are using round caps, whereupon
whatever direction the path is taken to have, the appearance will
be the same - and this we render the segment as a dot.
We have code in the renderer already to do this, but it looks to
me like it could be fooled into leaving a dot by us first doing
a move, a lineto the same point, and then a lineto to somewhere
else. The current code sets the 'dot' value to 1 when it detects
the degenerate line, and doesn't reset when it meets a
non-degenerate line later.
Accordingly I've changed the code here to account for such a
circumstance.
This produces no diffs in the cluster testing, but seems more
correct to me.
|
|
This is intended to be a way to allow us to implement
compiletime/runtime selection of different scan converter
implementations.
|
|
|
|
|
|
Decide whether to dash or not in the scan converter, not the
draw-device.
|
|
In all cases we reset the gel before populating it, so pull this
out of the draw device into the population routines.
|
|
|
|
In general, we should use 'const fz_blah' in device calls whenever
the callee should not alter the fz_blah.
Push this through. This shows up various places where we fz_keep
and fz_drop these const things.
I've updated the fz_keep and fz_drops with appropriate casts
to remove the consts. We may need to do the union dance to avoid
the consts for some compilers, but will only do that if required.
I think this is nicer overall, even allowing for the const<->no const
problems.
|
|
In fz_add_line_dot, if the flatness is too low, we can end
up with dots being 1 dimensional. Ensure that we always
use at least 3 vertexes to approximate a dot.
This was inspired by (but does not fix) bug 696172.
|
|
Previously out of range phase values were accepted which led to overly
long loops when processing moveto. This could be triggered e.g. by
2222222222222222222 [ 4 6 ] 0 d in a content stream.
|
|
In preparation for a bugfix concerning path phase.
|
|
Stroke segments that are horizontal or vertical get the same
antidropout treatment as filled rectangles.
|
|
This is not a complete general fix for features dropping out of
rendered line art, but merely a fix for one of the more common
cases.
When rendering rectangles (currently, specifically only those
rectangles that are actually defined as rectangles within the
path structure), if they are axis aligned, then ensure that they
always fill the subpixel line they are on.
|
|
Firstly, we make the definition of the path structures local to
path.c. This is achieved by using an fz_path_processor function to
step through paths enumerating each section using callback functions.
Next, we extend the internal path representation to include other
section types, including quads, beziers with common control points
rectangles, horizontal, vertical and degenerate lines. We also roll
close path sections up into the previous sections commands.
The hairiest part of this is that fz_transform_path has to cope with
changing the path commands depending on the matrix. This is a
relatively rare operation though.
|
|
Purge several embedded contexts:
Remove embedded context in fz_output.
Remove embedded context in fz_stream.
Remove embedded context in fz_device.
Remove fz_rebind_stream (since it is no longer necessary).
Remove embedded context in svg_device.
Remove embedded context in XML parser.
Add ctx argument to fz_document functions.
Remove embedded context in fz_document.
Remove embedded context in pdf_document.
Remove embedded context in pdf_obj.
Make fz_page independent of fz_document in the interface.
We shouldn't need to pass the document to all functions handling a page.
If a page is tied to the source document, it's redundant; otherwise it's
just pointless.
Fix reference counting oddity in fz_new_image_from_pixmap.
|
|
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.
|
|
|
|
|
|
|