| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The header of this file includes instructions for how to build it:
Compile using:
gcc -g -W -Wall -o svgtiny_display_x11 svgtiny_display_x11.c \
`pkg-config --cflags --libs libsvgtiny cairo` -lX11
That pkg-config command will generate the flags to link against the
installed copy of libsvgtiny. The line,
#include "svgtiny.h"
on the other hand, attempts to use a local header. This commit changes
that line to,
#include <svgtiny.h>
which will use the corresponding system header from whatever include
directory pkg-config hands us for libsvgtiny.
|
|
|
|
|
|
| |
This file uses malloc(), free(), and exit() -- all of which are
defined in stdlib.h. GCC seems unhappy about the situation, so we now
include it. This allows the file to be compiled once again.
|
|
|
|
|
|
| |
The svgtiny_LIBXML_ERROR constant was changed to throughout the
codebase to svgtiny_LIBDOM_ERROR a long time ago, in 9275ab308, but
this example was missed, probably because it isn't built by default.
|
|
|
|
|
|
| |
This constant svgtiny_LIBXML_ERROR was changed throughout the codebase
to svgtiny_LIBDOM_ERROR a long time ago, in 9275ab308, but the README
was missed because nobody reads the documentation :)
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Thanks to Nils for spotting this.
|
| |
|
| |
|
|
|
|
|
|
|
| |
Previously we built the generated code separatly and then linked to
it. However, this caused problems with certain compilers and gperf
versions. This change includes the generated code directly in
svgtiny.c instead, which is the only place its used.
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
One for fills and another for strokes. This stops an SVG such as
<svg viewBox="0 0 100 100" version="1.1" xmlns="http://www.w3.org/2000/svg">
<defs>
<linearGradient id="foo">
<stop stop-color="#69f" offset="0"/>
<stop stop-color="#468" offset="1"/>
</linearGradient>
</defs>
<path fill="url(#foo)" stroke='url(#bar)' d='M10 10 H 90 V 90 H 10 Z' />
</svg>
from getting its fill gradient details trampled when we reset the
gradient for the the missing bar gadient definition. Note, we only
handle linearGradient on the fill anyway.
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Generated with AFL using custom dictionary then minimised with cmin
and tmin tools to be the smallest test set possible
The run used two thousand processor hours on a 24way xeon 2.3GHz system
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
These svg files have caused the library to crash and to render poorly.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes bug #2251 which was caused by the svg:
<svg width="11" height="11" id="support-entry-icon"
y="3389"><g><g><path fill-rule="evenodd" clip-rule="evenodd"
fill="#D6D6D6" d="M0,0v11h11V0H0z M10,10H1V1h9V10z M9,3H2v1h7V3z
M9,5H2v1h7V5z M9,7H2v1h7V7z"/></g></g></svg>
The svg was causing more path elements to be generated in the internal
representation than space was allocated for and overrunning heap
blocks.
The path element parsing was using a fixed size allocation for the
path elements and never bounds checked. Further it did not cope with
zero length paths (which the spec says are permitted). It was also
grossly overallocating for the common case.
This changes the path element array to be bounds checked and then
extended if required, the initial allocation is generally sufficient
and in testing very few resizes occurred.
The reallocation strategy grows the element storage by 2.5 each time
this means even in the degenerate case very few reallocations are
required. In testing no more than a single reallocation has been
observed.
The final path element array will always be reallocted to the minimum
required size. This reduces overall memory usage which is useful with
complex scenes.
|
|
|
|
|
| |
Fix various issues with the test target and update the documentation
to be more correct.
|
| |
|
|
|
|
|
|
|
|
| |
The SVG spec for the transform attribute allows whitespace in places
that were causing the %n specifier in the ssanf to return 0 as the
match failed before it completed the parse.
http://www.w3.org/TR/SVG/coords.html#TransformAttribute
|
|
|
|
|
|
|
|
|
| |
Both 'M' and 'm' are moves and therefore start a new (sub)path. In
either case the location should be cached so that a later 'close path'
(z or Z) knows the location it is returning to. The location is not
written to 'p', since it is assumed that the client code remembers. If
the next move is relative (lowercase), then it's important that last_x,
last_y were correctly updated while processing Z/z.
|
| |
|
| |
|
|
|
|
| |
another.
|
| |
|
| |
|
| |
|
| |
|