[ODFPlugtest] Gouda plugfest: problem case with ODT frames encountered in OEP project
robert_weir at us.ibm.com
robert_weir at us.ibm.com
Wed Jan 4 00:03:59 CET 2012
This is very instructive. Thanks, Oliver.
In the OASIS ODF Interoperability and Conformance TC we are working on a
Committee Note (like a Technical Report) called "ODF Author for
Interoperability". It is about what a document author can do to ensure
that their documents are portable. Think of it like writing C/C++ code.
The langauge allows us to do non-portable things, like depend on the size
of an integer. But there are also best practices that allow us to write
portable code, if we know how and want to. The aim of this Committee Note
is to collect best practices related to ODF document authoring.
I think your examples of use of anchors could be useful for the paper.
-Rob
plugtest-bounces at opendocsociety.org wrote on 12/22/2011 10:09:35 AM:
> From: Oliver-Rainer Wittmann <ORWITT at de.ibm.com>
> To: Willem-Jan Veen <willem at lunatech.com>
> Cc: ODF Plugfest mailinglist <plugtest at opendocsociety.org>
> Date: 12/22/2011 10:14 AM
> Subject: Re: [ODFPlugtest] Gouda plugfest: problem case with ODT
> frames encountered in OEP project
> Sent by: plugtest-bounces at opendocsociety.org
>
>
> Hi Willem-Jan,
>
> this is a valuable example of how to get control about the vertical
> position of an object.
>
> Ok, the line is anchored at a more or less empty paragraph. This
paragraph
> has a set top margin (spacing above) of 0,85cm. Due to its own size and
its
> spacing above this empty paragraph moves to the next page. Thus, it
takes
> its anchored line with it to the next page. The vertical position of the
> line is given as 1,15cm from the top of the paragraph's area (called
> 'margin') in the user interface. Thus what happens when the paragraph is
> the first on a page? Its spacing above is not considered for the layout
> [1]. The vertical position of the line now becomes 0,85cm lower relative
to
> the paragraph as it would be, if the paragraph would be on the previous
> page on which its spacing above is considered. Thus, it is positioned
> inside the following paragraph, when the anchor paragraph is the first
one
> on a page..
>
> Solutions:
> (1) change the vertical positioning to "from top 0,3cm to paragraph text
> area" -> attached document ...solution01.odt (See attached file:
> Tractatenblad-experiment-solution01.odt)
>
> (2) change the anchoring of the line to to-character and change the
> vertical positioning to "below 0cm to character" -> attached
> document ...solution02.odt (See attached file:
> Tractatenblad-experiment-solution02.odt)
>
> In the attached documents I have made the changes to both lines in the
text
> document.
>
> I think with the knowledge you now got you will find further solutions
to
> stabilize the vertical position of the lines regardless of where the
anchor
> paragraph/character is on the page.
>
> I hope that these solutions can be generalized for your purposes.
> If you got further questions/problems, do not hesistate to get in
contact
> with me via this mailing list or the Apache OpenOffice (incubating)
> ooo-dev at incubator.apache.org mailing list. You will also find further
help
> and support at the Apache OpenOffice (incubating) forums
> http://user.services.openoffice.org
>
>
> Mit freundlichen Grüßen / Best regards
> Oliver-Rainer Wittmann
>
> [1] This is common. Only in special cases the spacing above is
considered,
> when the paragraph is the first one on a page - e.g. for the first
> paragraph on the first page of the text document the spacing above is
> considered.
>
> --
> Advisory Software Engineer
>
-------------------------------------------------------------------------------------------------------------------------------------------
>
> IBM Deutschland
> Beim Strohhause 17
> 20097 Hamburg
> Phone: +49-40-6389-1415
> E-Mail: orwitt at de.ibm.com
>
-------------------------------------------------------------------------------------------------------------------------------------------
>
> IBM Deutschland Research & Development GmbH / Vorsitzende des
> Aufsichtsrats: Martina Koederitz
> Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
Stuttgart,
> HRB 243294
>
>
>
> From: Willem-Jan Veen <willem at lunatech.com>
> To: Oliver-Rainer Wittmann/Germany/IBM at IBMDE
> Cc: ODF Plugfest mailinglist <plugtest at opendocsociety.org>
> Date: 24.11.2011 11:33
> Subject: Re: [ODFPlugtest] Gouda plugfest: problem case with ODT
frames
> encountered in OEP project
>
>
>
> Hi Olivier-Rainer,
>
> I've made the other scenario showing a problem with flow (float)
semantics.
> This time it relates to a paragraph containing a draw:line element, that
> didn't fit on a page. As a result, the line flows to the next page
(good)
> on top of the text in the following paragraph (wrong).
>
> See the attached sample document that I've stripped to the bare minimum
for
> show casing the observed behaviour. Again, I hope you understand better
> what is going on and maybe know a way to resolve this issue.
>
> Many thanks in advance.
>
> Regards,
>
> Willem-Jan
>
> [attachment "Tractatenblad-experiment.odt" deleted by Oliver-Rainer
> Wittmann/Germany/IBM]
>
>
> On Nov 23, 2011, at 2:25 PM, Oliver-Rainer Wittmann wrote:
>
> > Hi Willem-Jan,
> >
> > we already had the possibility to talk at the end of the ODF Plugfest
in
> > Gouda, NL last week about your layout problems in some detail.
> > I think I have already given you some hints in order to get more
control
> > about the layout regarding the flow of text frames in OpenOffice.org
> resp.
> > Apache OpenOffice.
> >
> > As promised I am planning to followup on your problems in more detail
> when
> > I have some resources left. Hopefully, I have some time in the next
week.
> > I hope it is ok for the rest of the mailing list subscribers, if I
post
> the
> > followup on this mailing list, because - as far as I have seen - the
> > problems are more or less related to applications which base on
> > OpenOffice.org code than they are related to ODF.
> > If not, please let me know.
> >
> > Willem-Jan: Do not hestitate to ping me, if you have
> questions/comments/...
> >
> >
> > Mit freundlichen Grüßen / Best regards
> > Oliver-Rainer Wittmann
> >
> > --
> > Advisory Software Engineer
> >
>
-------------------------------------------------------------------------------------------------------------------------------------------
>
> >
> > IBM Deutschland
> > Beim Strohhause 17
> > 20097 Hamburg
> > Phone: +49-40-6389-1415
> > E-Mail: orwitt at de.ibm.com
> >
>
-------------------------------------------------------------------------------------------------------------------------------------------
>
> >
> > IBM Deutschland Research & Development GmbH / Vorsitzender des
> > Aufsichtsrats: Martin Jetter
> > Geschäftsführung: Dirk Wittkopp
> > Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
> Stuttgart,
> > HRB 243294
> >
> >
> >
> > From: Willem-Jan Veen <willem at lunatech.com>
> > To: plugtest at opendocsociety.org
> > Date: 18.11.2011 10:45
> > Subject: [ODFPlugtest] Gouda plugfest: problem case with ODT
> frames
> > encountered in OEP project
> > Sent by: plugtest-bounces at opendocsociety.org
> >
> >
> >
> > Hi,
> >
> > The problem case with frames concern for instance the inclusion of an
> image
> > with a title on top and additional remarks on the bottom. In the
specific
> > situation that the image doesn't fit on the remainder of the page, it
> > automatically floats to the next page (what is good), but the
positioning
> > of the frames with title, image and remarks become scrambled.
> >
> > I've attached a small ODT file which demonstrates this behaviour. It
> first
> > shows a image with title and remarks which are rendered correctly
> position
> > to each other. A page further, in identical example is presented but
this
> > time the image didn't fit on the remainder of the page and floated to
the
> > next page. You can immediately see the resulting visual effects when
> opened
> > in openoffice or neo-office.
> >
> > Please note, that the ODT isn't correctly zipped. The original ODT was
> much
> > larger, so I unzipped de ODT, manually removed as much content as
> possible
> > while keeping the problem case intact. I then zipped the ODT quickly
by
> > hand without placing the file mime type as-is on the starting offset.
In
> > our experience, this doesn't pose a problem for rendering such a
document
> > in a word processor. The real system does do the final zip process
> > according to specification.
> >
> > Regards,
> > Willem-Jan Veen
> >
> > [attachment "KIO-exoeriment.odt" deleted by Oliver-Rainer
> > Wittmann/Germany/IBM] _______________________________________________
> > Plugtest mailing list
> > Plugtest at opendocsociety.org
> > http://lists.opendocsociety.org/mailman/listinfo/plugtest
> >
>
> [attachment "Tractatenblad-experiment-solution01.odt" deleted by
> Robert Weir/Cambridge/IBM] [attachment "Tractatenblad-experiment-
> solution02.odt" deleted by Robert Weir/Cambridge/IBM]
> _______________________________________________
> Plugtest mailing list
> Plugtest at opendocsociety.org
> http://lists.opendocsociety.org/mailman/listinfo/plugtest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open.nlnet.nl/pipermail/plugtest/attachments/20120103/d2025a28/attachment.html>
More information about the Plugtest
mailing list