<symbol> not rendered correctly in exported PDF
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Inkscape |
Fix Released
|
Medium
|
theAdib | ||
| inkscape (Ubuntu) |
Fix Released
|
Low
|
Unassigned | ||
Bug Description
attached svg is not rendered correctly in pdf.
This is a follow up from https:/
and addresses the not mentioned issues.
Issues here:
1. too many red dots : rendering the svg:symbol where it should not render
2. no symbol in red dot : this is because not inheriting the fill-rule from group to inner element/group
Related branches
Patch tested with Inkscape 0.46+devel r22293 on OS X 10.5.8
PDF export settings: default (new preferences.xml)
can not confirm fix for PDF export of symbols: I still get
- 4 instead of 2 red circles in PDF
- no symbol rendered inside the red circles
I forgot to check the make console output: found some error messages when compiling with your patch applied.
- BUG436962_symbolassymbol.diff Edit (1.6 KiB, text/plain)
~suv I will reattach the patch now against recent svn 22524. This patch replaces that from #2. Adib.
- cairo-renderer.cpp Edit (24.5 KiB, text/x-c++src)
to simplify I attach as well the my recent version. src/extension/
FYI there might be something else not good in your build because the compiler only outputs warnings whereas the linker misses symbols.
FYI there might be something else not good in your build because the compiler only outputs warnings whereas the linker misses symbols.
theAdib.
> only outputs warnings whereas the linker misses symbols
Strange - why would 'make' even have built 'filedialogimpl
- 436962-inkscape-LeWitt-r22528+patch.pdf Edit (31.9 KiB, application/pdf)
patch tested and partial fix confirmed with Inkscape 0.46+devel r22528+patch on OS X 10.5.8
> Issues here:
> 1. too many red dots
confirmed fixed (see attached PDF file)
> 2. no symbol in red dot
still open
+ <symbol> not rendered correctly in exported PDF
I still see 4 red circles with no symbols, using inkscape_
@theAdlib - Are you still working on a fix for this?
Sorry - "@theAdib"
Possibly related reports about instantiated <symbol>s with viewbox attributes incorrectly exported to PDF (confirmed with current trunk and cairo 1.10.2):
Bug #485846 "imported svg not exportable to eps"
Bug #705345 "Cairo rendering broken for "use" elements with scaling or a viewBox"
Tested with r10197 (with patch for bug #705345) on Mac OS X 10.5.8 (i386), cairo 1.10.2:
The symbol definitions themselves are no longer exported (compared to PDF exported with r10196 with 4 red circles there are only two red circles in r10197).
The remaining issue - both red circles are still rendered filled (instead of showing a white fill in the cut-out area) - seems unrelated to the <symbol> problem because the cairo-based export apparently ignores the fill rule which is set on a parent group instead of the red path itself (which isn't an instantiated symbol (<use> element) btw).
- better fill rule handling Edit (1.4 KiB, text/plain)
I investigated further and I hope I found a good patch for this.
Please test on many samples it might have a large side effects.
patch is committed in revision 10200.
theAdib.