libcdr-based CDR importing flips images vertically
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Inkscape |
Invalid
|
Medium
|
Unassigned | ||
Inkscape Devlibs |
Fix Released
|
Medium
|
jazzynico |
Bug Description
There's a bunch of bugs with libcdr-based importer of CDR files, most notably all bitmaps are flipped vertically. Personally, I suspect it has something to do with incorrect reading coordinates.
Here's what Inkscape does:
https:/
While here's what cdr2odg produces:
https:/
Here's the file:
https:/
And here's PDF preview:
https:/
It would be great if Fridrich could be persuaded to still add saving flowed text output. I know we screwed that one up, but we do need a workaround.
Changed in inkscape-devlibs: | |
assignee: | nobody → JazzyNico (jazzynico) |
importance: | Undecided → Medium |
status: | New → Triaged |
Changed in inkscape-devlibs: | |
assignee: | jazzynico (jazzynico) → nobody |
Changed in inkscape-devlibs: | |
assignee: | nobody → jazzynico (jazzynico) |
status: | Triaged → In Progress |
> Here's what Inkscape does:
Inkscape simply renders what SVG it receives from libcdr - there is no additional processing of the content on inkscape's side at all. libcdr's command line tool 'cdr2xhtml' produces the same output (inverted embedded images) as gets imported to Inkscape. IMHO this ought to be filed for libcdr, not inkscape: www.freedesktop .org/wiki/ Software/ libcdr> bugs.freedeskto p.org/>
<http://
<http://
> It would be great if Fridrich could be persuaded to still add saving flowed text
> output. I know we screwed that one up, but we do need a workaround.
To quote from an earlier conversation on #inkscape: /bobswift. atlassian. net/wiki/ display/ CVP/How+ to+install+ SVG+conversion+ support :) and files bugs about absence of wrapped text in SVG cgit.freedeskto p.org/libreoffi ce/libcdr/ tree/src/ lib/CDRSVGGener ator.cpp> ? cgit.freedeskto p.org/libreoffi ce/contrib/ libvisio/ tree/src/ lib/VSDSVGGener ator.cpp>
12:46 TrainedMonkey : su_v: funny enough, we discovered that someone uses libvisio here https:/
12:46 su_v : with those I get the same results (mostly, except for multi-line text) as shown in the LO screenshots
12:46 TrainedMonkey : su_v: yeah, text is a problem
12:49 TrainedMonkey : su_v: if someone from inkscape decides to maintain the svg part, I am ready to allow sodipodi namespace there, along with using your text-frames, but will not do it if it is only me working on it, since I don't use the svg for other purpose then quick viewing of the pics
12:50 su_v : TrainedMonkey: based on current developer activity in Inkscape trunk, I doubt this will happen :(
12:50 su_v : OTOH one never knows ;)
12:50 TrainedMonkey : exactly, it is good to wait, it is sweet to hope
12:51 su_v : There is a blueprint to refactor Inkscape's internal <text> handling completely (since current 'Flowed Text' isn't a solution either)
12:51 su_v : not compliant with the SVG 1.1 spec, not supported by other SVG renderers
12:51 su_v : etc.
12:53 su_v : (no fallback, or <switch> variant)
12:54 TrainedMonkey : yeah, that is why I did not bother
12:54 TrainedMonkey : the same with svg multi-page stuff that nobody supports
12:58 su_v : the "svg part" would be <http://
12:58 TrainedMonkey : su_v: sure
12:59 TrainedMonkey : that is the class that takes the api callbacks and converts into svg xml
12:59 TrainedMonkey : su_v: I just tested btw, and my own mingw-built icu works well at least for russian ecoding
12:59 TrainedMonkey : encoding
12:59 su_v : and <http://