Calligra-devel is a list for the discussion of development related issues of the Calligra suite. User questions are welcome as well. ()

Friedrich W. H. Kossebau | 10 Feb 13:19 2012

CDR import - map to what format?

Hi,

so I have been progressing a little bit with the CDR import filter, I know 
more and more about the format. Still not enough to render the first things in 
their place, but e.g. I can now access all raw text, both from graphic text 
objects as block text objects.

I also turned to stream some SVG as output from the filter, as I could not 
create a Karbon working-memory document directly without many hacks.

Just, I have found out now that mapping to SVG as a native Karbon format does 
not really work, without losing information. In CDR possible, but not Karbon:
* multiple pages
* text block element (non-graphic text)
* rectangles have more properties than svg rectangle shape¹
* objects can be auto-updated clones
  (not yet seen, just remember this feature)

¹ http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-
free-software-gets-another-chance (section "The hard part")

So what do I do about that? For the rectangles I would have guessed I could 
try to write a custom shape which supports all those properties. The text 
blocks could have been the TextShape, but how would those be loaded from SVG? 
What about the multiple pages?

Also, seems there is no odg import filter for Karbon. Noone working on this? 
ODG (which seems to also support multiple pages, at least LibreOffice draw 
allows this) not yet supported?

(Continue reading)

headers

Sven Langkamp | 10 Feb 15:23 2012

Re: CDR import - map to what format?

On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau <kossebau <at> kde.org> wrote:

Hi,

so I have been progressing a little bit with the CDR import filter, I know
more and more about the format. Still not enough to render the first things in
their place, but e.g. I can now access all raw text, both from graphic text
objects as block text objects.

I also turned to stream some SVG as output from the filter, as I could not
create a Karbon working-memory document directly without many hacks.

Just, I have found out now that mapping to SVG as a native Karbon format does
not really work, without losing information. In CDR possible, but not Karbon:
* multiple pages
* text block element (non-graphic text)
* rectangles have more properties than svg rectangle shape¹
* objects can be auto-updated clones
(not yet seen, just remember this feature)

¹ http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-
free-software-gets-another-chance (section "The hard part")

So what do I do about that? For the rectangles I would have guessed I could
try to write a custom shape which supports all those properties. The text
blocks could have been the TextShape, but how would those be loaded from SVG?
What about the multiple pages?

Also, seems there is no odg import filter for Karbon. Noone working on this?
ODG (which seems to also support multiple pages, at least LibreOffice draw
allows this) not yet supported?

Odg is a native format in Karbon. You can open any odg files, the only limitation is that only one page is opened. Flow can open odg files with multiple pages. That's also a reason why in earlier discussion it was suggested to convert to a file and not directly to the memory model. That way Karbon and Flow could make use of the filter.

SVG doesn't support multiple pages. With odg pages and text blocks could be done much better. So I would suggest that you try to use odg as target file format.

That would also have the advantage that LibreOffice and Calligra could use it. With the same target format it would be possible to merge your work and libcdr, so the whole work could be shared.

<div><div class="gmail_quote">On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau <span dir="ltr">&lt;<a href="mailto:kossebau@...">kossebau <at> kde.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hi,<br><br>
so I have been progressing a little bit with the CDR import filter, I know<br>
more and more about the format. Still not enough to render the first things in<br>
their place, but e.g. I can now access all raw text, both from graphic text<br>
objects as block text objects.<br><br>
I also turned to stream some SVG as output from the filter, as I could not<br>
create a Karbon working-memory document directly without many hacks.<br><br>
Just, I have found out now that mapping to SVG as a native Karbon format does<br>
not really work, without losing information. In CDR possible, but not Karbon:<br>
* multiple pages<br>
* text block element (non-graphic text)<br>
* rectangles have more properties than svg rectangle shape&sup1;<br>
* objects can be auto-updated clones<br>
 &nbsp;(not yet seen, just remember this feature)<br><br>
&sup1; <a href="http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-%0Afree-software-gets-another-chance" target="_blank">http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-<br>
free-software-gets-another-chance</a> (section "The hard part")<br><br>
So what do I do about that? For the rectangles I would have guessed I could<br>
try to write a custom shape which supports all those properties. The text<br>
blocks could have been the TextShape, but how would those be loaded from SVG?<br>
What about the multiple pages?<br><br>
Also, seems there is no odg import filter for Karbon. Noone working on this?<br>
ODG (which seems to also support multiple pages, at least LibreOffice draw<br>
allows this) not yet supported?<br>
</blockquote>
<div>
<br>Odg is a native format in Karbon. You can open any odg files, the only limitation is that only one page is opened. Flow can open odg files with multiple pages. That's also a reason why in earlier discussion it was suggested to convert to a file and not directly to the memory model. That way Karbon and Flow could make use of the filter.<br><br>SVG doesn't support multiple pages. With odg pages and text blocks could be done much better. So I would suggest that you try to use odg as target file format.<br><br>That would also have the advantage that LibreOffice and Calligra could use it. With the same target format it would be possible to merge your work and libcdr, so the whole work could be shared.<br>
</div>
</div></div>

headers

Friedrich W. H. Kossebau | 13 Feb 10:31 2012

Re: CDR import - map to what format?

Hi Sven,

Am Freitag, 10. Februar 2012, 15:23:37 schrieb Sven Langkamp:
> On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau
> 
> <kossebau@...>wrote:
> > Hi,
> > 
> > so I have been progressing a little bit with the CDR import filter, I
> > know more and more about the format. Still not enough to render the
> > first things in
> > their place, but e.g. I can now access all raw text, both from graphic
> > text objects as block text objects.
> > 
> > I also turned to stream some SVG as output from the filter, as I could
> > not create a Karbon working-memory document directly without many
> > hacks.
> > 
> > Just, I have found out now that mapping to SVG as a native Karbon format
> > does
> > not really work, without losing information. In CDR possible, but not
> > Karbon:
> > * multiple pages
> > * text block element (non-graphic text)
> > * rectangles have more properties than svg rectangle shape¹
> > * objects can be auto-updated clones
> > 
> >  (not yet seen, just remember this feature)
> > 
> > ¹
> > http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in
> > -
> > free-software-gets-another-chance (section "The hard part")
> > 
> > So what do I do about that? For the rectangles I would have guessed I
> > could try to write a custom shape which supports all those properties.
> > The text blocks could have been the TextShape, but how would those be
> > loaded from SVG?
> > What about the multiple pages?
> > 
> > Also, seems there is no odg import filter for Karbon. Noone working on
> > this?
> > ODG (which seems to also support multiple pages, at least LibreOffice
> > draw allows this) not yet supported?
> 
> Odg is a native format in Karbon. You can open any odg files, the only
> limitation is that only one page is opened. Flow can open odg files with
> multiple pages. That's also a reason why in earlier discussion it was
> suggested to convert to a file and not directly to the memory model. That
> way Karbon and Flow could make use of the filter.
> 
> SVG doesn't support multiple pages. With odg pages and text blocks could be
> done much better. So I would suggest that you try to use odg as target file
> format.

Ah, I have not seen (maybe did not long good enough) an existing filter 
creating an ODG stream, only SVG-creating ones. Okay, will switch to stream an 
ODG then.

> That would also have the advantage that LibreOffice and Calligra could use
> it. With the same target format it would be possible to merge your work and
> libcdr, so the whole work could be shared.

Yep, or at least to compare better what the two codebases are doing :) Though 
they have different approaches: libcdr reads the data element by element, 
while my filter reads complete RIFF chunks one-by-one and maps 
pointer/references of the proper structs onto the chunk to access the 
elements. Having these two variants is also a nice experiment to see which 
approach works out better.

Thanks for the answer! :)
Friedrich

headers

Sven Langkamp | 10 Feb 15:51 2012

Re: CDR import - map to what format?

On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau <kossebau-RoXCvvDuEio@public.gmane.org> wrote:

Hi,

so I have been progressing a little bit with the CDR import filter, I know
more and more about the format. Still not enough to render the first things in
their place, but e.g. I can now access all raw text, both from graphic text
objects as block text objects.

I also turned to stream some SVG as output from the filter, as I could not
create a Karbon working-memory document directly without many hacks.

Just, I have found out now that mapping to SVG as a native Karbon format does
not really work, without losing information. In CDR possible, but not Karbon:
* multiple pages
* text block element (non-graphic text)
* rectangles have more properties than svg rectangle shape¹
* objects can be auto-updated clones
(not yet seen, just remember this feature)

¹ http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-
free-software-gets-another-chance (section "The hard part")

So what do I do about that? For the rectangles I would have guessed I could
try to write a custom shape which supports all those properties.

Odg does already have a custom shape that could do that. It's already in Calligra as the EnhancedPathShape.
That allows to have a shape based on a formula and custom handles.

<div>
<br><br><div class="gmail_quote">On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau <span dir="ltr">&lt;<a href="mailto:kossebau@...">kossebau@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">
Hi,<br><br>
so I have been progressing a little bit with the CDR import filter, I know<br>
more and more about the format. Still not enough to render the first things in<br>
their place, but e.g. I can now access all raw text, both from graphic text<br>
objects as block text objects.<br><br>
I also turned to stream some SVG as output from the filter, as I could not<br>
create a Karbon working-memory document directly without many hacks.<br><br>
Just, I have found out now that mapping to SVG as a native Karbon format does<br>
not really work, without losing information. In CDR possible, but not Karbon:<br>
* multiple pages<br>
* text block element (non-graphic text)<br>
* rectangles have more properties than svg rectangle shape&sup1;<br>
* objects can be auto-updated clones<br>
 &nbsp;(not yet seen, just remember this feature)<br><br>
&sup1; <a href="http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-%0Afree-software-gets-another-chance" target="_blank">http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-<br>
free-software-gets-another-chance</a> (section "The hard part")<br><br>
So what do I do about that? For the rectangles I would have guessed I could<br>
try to write a custom shape which supports all those properties.<br>
</blockquote>
<div>
<br>Odg does already have a custom shape that could do that. It's already in Calligra as the EnhancedPathShape.<br>That allows to have a shape based on a formula and custom handles.<br>
</div>
</div>
</div>

headers

Friedrich W. H. Kossebau | 13 Feb 10:31 2012

Re: CDR import - map to what format?

Am Freitag, 10. Februar 2012, 15:51:34 schrieb Sven Langkamp:
> On Fri, Feb 10, 2012 at 1:19 PM, Friedrich W. H. Kossebau
> 
> <kossebau@...>wrote:
> > So what do I do about that? For the rectangles I would have guessed I
> > could try to write a custom shape which supports all those properties.
> Odg does already have a custom shape that could do that. It's already in
> Calligra as the EnhancedPathShape.
> That allows to have a shape based on a formula and custom handles.

Okay, that was the one I was thinking of :)

Friedrich

headers

Thorsten Zachmann | 11 Feb 05:02 2012

Re: CDR import - map to what format?

On Friday, February 10, 2012 13:19:16 Friedrich W. H. Kossebau wrote:
> Hi,
> 
> so I have been progressing a little bit with the CDR import filter, I know
> more and more about the format. Still not enough to render the first things
> in their place, but e.g. I can now access all raw text, both from graphic
> text objects as block text objects.
> 
> I also turned to stream some SVG as output from the filter, as I could not
> create a Karbon working-memory document directly without many hacks.
> 
> Just, I have found out now that mapping to SVG as a native Karbon format
> does not really work, without losing information. In CDR possible, but not
> Karbon: * multiple pages

One way to work around this limition would be to load each page into a 
different layer. There are already some filters doing that.

> * text block element (non-graphic text)

That is saved as ArtisticTextShape in svg as a short text shows. That means if 
you save it in svg you will not be able to have it as text shape.

> * rectangles have more properties than svg rectangle shape¹

To support that you can use a enhanced path shape (a feature of odf). Not sure 
how much work it is to map the shape from cdr to odf. Or just convert the 
shape to a path shape. That will leave you will a correctly displayed shape 
but it will loose the ability to have special ways of editing

> * objects can be auto-updated clones
>   (not yet seen, just remember this feature)
> 
> ¹ http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-in-
> free-software-gets-another-chance (section "The hard part")
> 
> So what do I do about that? For the rectangles I would have guessed I could
> try to write a custom shape which supports all those properties. The text
> blocks could have been the TextShape, but how would those be loaded from
> SVG? What about the multiple pages?
> 
> Also, seems there is no odg import filter for Karbon. Noone working on
> this? ODG (which seems to also support multiple pages, at least
> LibreOffice draw allows this) not yet supported?

Flow does allow loading multiple page.

The way to go depends on what you think is more needed. If you want to use 
some effects on your shapes then svg might be the better solution. If that 
might not be needed the odg might be the better choice.

Hope that helps,

Thorsten

headers

Friedrich W. H. Kossebau | 13 Feb 10:36 2012

Re: CDR import - map to what format?

Hi Thorsten,

Am Samstag, 11. Februar 2012, 05:02:29 schrieb Thorsten Zachmann:
> On Friday, February 10, 2012 13:19:16 Friedrich W. H. Kossebau wrote:
> > Hi,
> > 
> > so I have been progressing a little bit with the CDR import filter, I
> > know more and more about the format. Still not enough to render the
> > first things in their place, but e.g. I can now access all raw text,
> > both from graphic text objects as block text objects.
> > 
> > I also turned to stream some SVG as output from the filter, as I could
> > not create a Karbon working-memory document directly without many
> > hacks.
> > 
> > Just, I have found out now that mapping to SVG as a native Karbon format
> > does not really work, without losing information. In CDR possible, but
> > not Karbon: * multiple pages
> 
> One way to work around this limition would be to load each page into a
> different layer. There are already some filters doing that.

Works for my files I think, but maybe not for everyone else :/

> > * text block element (non-graphic text)
> 
> That is saved as ArtisticTextShape in svg as a short text shows. That means
> if you save it in svg you will not be able to have it as text shape.

Yes, and not really what I want (for my files).

> > * rectangles have more properties than svg rectangle shape¹
> 
> To support that you can use a enhanced path shape (a feature of odf). Not
> sure how much work it is to map the shape from cdr to odf. Or just convert
> the shape to a path shape. That will leave you will a correctly displayed
> shape but it will loose the ability to have special ways of editing

Just display might not satisfy everyone, so enhanced path shape I will be 
looking at.

> > * objects can be auto-updated clones
> > 
> >   (not yet seen, just remember this feature)
> > 
> > ¹
> > http://libregraphicsworld.org/blog/entry/support-for-corel-draw-files-i
> > n- free-software-gets-another-chance (section "The hard part")
> > 
> > So what do I do about that? For the rectangles I would have guessed I
> > could try to write a custom shape which supports all those properties.
> > The text blocks could have been the TextShape, but how would those be
> > loaded from SVG? What about the multiple pages?
> > 
> > Also, seems there is no odg import filter for Karbon. Noone working on
> > this? ODG (which seems to also support multiple pages, at least
> > LibreOffice draw allows this) not yet supported?
> 
> Flow does allow loading multiple page.

Until Karbon does at well, that might be a workaround. But then those program 
concepts are just work-flow artifacts, given the composed nature of the 
document type :)

> The way to go depends on what you think is more needed. If you want to use
> some effects on your shapes then svg might be the better solution. If that
> might not be needed the odg might be the better choice.

So those effects cannot be mapped to ODG? Could't I simply embed SVG into ODG?

Cheers
Friedrich

headers

Thorsten Zachmann | 13 Feb 12:07 2012

Re: CDR import - map to what format?

Hi 

On Monday, February 13, 2012 10:36:28 Friedrich W. H. Kossebau wrote:
> Hi Thorsten,
> > 
> > Flow does allow loading multiple page.
> 
> Until Karbon does at well, that might be a workaround. But then those
> program concepts are just work-flow artifacts, given the composed nature
> of the document type :)

If you export to odg then the files can be opened in karbon and flow.

> > The way to go depends on what you think is more needed. If you want to
> > use some effects on your shapes then svg might be the better solution.
> > If that might not be needed the odg might be the better choice.
> 
> So those effects cannot be mapped to ODG? Could't I simply embed SVG into
> ODG?

Yes you can. However I'm not sure how good the support for those is in 
Calligra at the moment. Last time it was checked at the odf plugfest and there 
it did not work. However there was a patch to make it work.

Thorsten