MHonArc v2.5.0b2 -->
office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] Text Object position
I discovered today that an old issue hasn't been resolved yet, I think we forgot about it.
On Friday 27 February 2004 15:50, Michael Brauer wrote:
> Hi David,
>
> David Faure wrote:
> > I have a suggestion for an improvement in the way we specify the position of
> > text objects (or even drawing objects in general).
> > What about saving their position (svg:x and svg:y) as redundant information,
> > for applications that don't implement all the positioning capabilites of e.g. OOWriter?
> >
> > For instance I saved a text-box with the default settings in OO, and it was anchored
> > to the paragraph, and centered within the paragraph.
> >
> > <draw:text-box svg:width="6.786cm" draw:name="Cadre1" fo:min-height="8.652cm"
> > draw:style-name="fr1" draw:z-index="0" text:anchor-type="paragraph" >
(of course this would now be <draw:frame> with <draw:text-box> inside; and this
issue applies to all types of frames, not only text boxes)
> > <style:style style:name="fr1" style:family="graphics" style:parent-style-name="Frame" >
> > <style:properties style:vertical-pos="top" style:horizontal-pos="center"
> > style:horizontal-rel="paragraph" style:vertical-rel="paragraph-content" />
> > </style:style>
> >
> > If the application reading this doesn't implement centering of inline elements
> > in paragraphs, the text box will be wrongly placed. Can we specify that the
> > initial application should save the x and y (relative to the page topleft corner),
> > so that less-advanced applications and conversion filters know where to place it?
>
> Until now, I did not find a solution for this issue. I think we should
> discuss this issue again on Monday.
The minutes for March 1st 2004 mention that we both missed that call, so the
topic was postponed, and further minutes don't mention the topic at all.
> David Faure wrote:
> > Much like we specified that the number in front of numbered paragraph should be saved,
> > even though it can be in theory recalculated. It removes the need for the reader
> > to implement the full algorithm for numbered paragraphs in that case, or the
> > full layouting algorithm for the text-box case. (Imagine trying to place the above text box in
> > an HTML/CSS export filter).
I have an even more telling example of why this is needed. In the attached document, a frame
is anchored to a paragraph, and is positioned to the left of the paragraph, with the setting that
the text should wrap around the frame.
So the position of the frame depends on the position of the text, and vice-versa...
Without a full layouter that supports anchoring frames to paragraphs and that can handle
such a tricky situation, it's impossible to know where the frame should go.
My proposal is to add the following optional attributes to the draw:frame element:
draw:page-x, and draw:page-y, the coordinates of the frame within the page.
When an application saves a frame using any type of anchoring other than "page",
it would save those coordinates in addition to svg:x and svg:y (which are the relative
coordinates - relative to paragraph, or character, depending on the type of anchoring).
This can be used by simpler applications (e.g. kword doesn't support the 5 types of
anchoring) and by simpler export formats (e.g. HTML/CSS doesn't either) in order
to position the frame at the right place, i.e. the same place as it was in the initial
document. Of course the link to the paragraph is lost, but that's expected anyway
if the application or output format doesn't support anchoring to a paragraph.
--
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
114287-oneframe.odt
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]