[prev in list] [next in list] [prev in thread] [next in thread]
List: calligra-devel
Subject: Re: KoReport ODT Renderer
From: Adam Pigg <piggz1 () gmail ! com>
Date: 2012-04-25 9:10:14
Message-ID: 4648248007963001719 () unknownmsgid
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
you have identified the same issue i did 2 years ago :-)
I can't check right now, but i think the existing odt generator arranges
the items in a table. Perhaps there is space for both types of output? The
html generator works like this..there are 2, one that outputs as a table,
the other outputs div blocks with css.
--
Sent from my Nokia N9
On 25/04/2012 9:51 Dag wrote:
S=F8ndag den 22. april 2012 16:35:34 Adam Pigg skrev:
> Dag
>
> In Plan, i see you have your own ODT renderer. It appears to be more
> featureful than the one in libs/koreport, so perhaps you could move it
> there?
Done, branch: report_odt_danders
> Can you post a sample of what kind of ODT it produces?
Ok, I have looked more closely into this and found some problems that makes
it
difficult to export to odt in usefull manner.
Imo the reason (often) to export to odt is to be able to edit the document
afterwards, to add comments and evaluations. Hence it needs to be easily
editable while still presenting the data formatted the same way it was in
the
original report.
Reports are built up of items (label, field, picture etc) that correspond
very
well with shapes in words (frame in odt). So in my current implementation I
just create a frame for each item in the report with the same size and
position. This looks good, but is mostly useless as the a document
consisting
of individual frames is for all practical purposes impossible to edit.
One could argue that reports often consists of tabular data so it should be
just to put it into a table, right?
Well, yes *sometimes* it could work well, other times no because the repor=
t
designer are able to position his items *very* freely in a way that makes i=
t
very, very difficult to put it into a table.
One solution to this would be to introduce the conceptof tables into the
report designer. Thus it is up to the user to decide when to use table and
when to use individual frames. This has the additional benfit that it the
designer will be *much* easier to use, creating a "table" today is a seriou=
s
pain.
Another problem in odt export is headers/footers. Afaics it is not possible
to
use frames inside these in neither words nor LO. Plain text or tables work
fine, but alas, not frames.
Solution? I have none.
Any ideas?
--
Mvh.
Dag Andersen
[Attachment #5 (text/html)]
<html><head></head><body><div id="fenix-user-content">
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><span \
style="font-family:'NokiaPureTextLight'">you have identified the same issue i \
did 2 years ago :-) </span></p> <p \
style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px;font-family:'NokiaPureTextLight'"><br></p>
<p style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><span \
style="font-family:'NokiaPureTextLight'">I can't check right now, but i \
think the existing odt generator arranges the items in a table. Perhaps there is \
space for both types of output? The html generator works like this..there are 2, one \
that outputs as a table, the other outputs div blocks with css.<br> \
<br>--<br></span></p> <p \
style="margin-top:0px;margin-bottom:0px;margin-left:0px;margin-right:0px;text-indent:0px"><span \
style="font-family:'NokiaPureTextLight'">Sent from my Nokia \
N9<br></span></p></div><br><div id="fenix-reply-header"> <p>On 25/04/2012 9:51 Dag \
wrote:<br></p></div><div id="fenix-quoted-body">Søndag den 22. april 2012 16:35:34 \
Adam Pigg skrev:<br> > Dag<br>
><br>
> In Plan, i see you have your own ODT renderer. It appears to be more<br>
> featureful than the one in libs/koreport, so perhaps you could move it<br>
> there?<br>
Done, branch: report_odt_danders<br>
> Can you post a sample of what kind of ODT it produces?<br>
<br>
Ok, I have looked more closely into this and found some problems that makes it<br>
difficult to export to odt in usefull manner.<br>
Imo the reason (often) to export to odt is to be able to edit the document<br>
afterwards, to add comments and evaluations. Hence it needs to be easily<br>
editable while still presenting the data formatted the same way it was in the<br>
original report.<br>
<br>
Reports are built up of items (label, field, picture etc) that correspond very<br>
well with shapes in words (frame in odt). So in my current implementation I<br>
just create a frame for each item in the report with the same size and<br>
position. This looks good, but is mostly useless as the a document consisting<br>
of individual frames is for all practical purposes impossible to edit.<br>
<br>
One could argue that reports often consists of tabular data so it should be<br>
just to put it into a table, right?<br>
Well, yes *sometimes* it could work well, other times no because the report<br>
designer are able to position his items *very* freely in a way that makes it<br>
very, very difficult to put it into a table.<br>
<br>
One solution to this would be to introduce the conceptof tables into the<br>
report designer. Thus it is up to the user to decide when to use table and<br>
when to use individual frames. This has the additional benfit that it the<br>
designer will be *much* easier to use, creating a "table" today is a \
serious<br> pain.<br>
<br>
Another problem in odt export is headers/footers. Afaics it is not possible to<br>
use frames inside these in neither words nor LO. Plain text or tables work<br>
fine, but alas, not frames.<br>
<br>
Solution? I have none.<br>
Any ideas?<br>
<font color="#888888"><br>
<br>
--<br>
Mvh.<br>
Dag Andersen<br>
</font></div><br></body></html>
_______________________________________________
calligra-devel mailing list
calligra-devel@kde.org
https://mail.kde.org/mailman/listinfo/calligra-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic