Created attachment 127046 [details] input or original test document As the attached files show, the per-paragraph paragraphs ("marginalia") show at the top of each page, rather than to the correct margin placement side (left or right (mirrored margins)), beside each each respective paragraph. Libreoffice frame styles are capable of correct placement (I've tested this, can supply an example test file if needed - LO marginalia examples are also available on the web). Only one attachment allowed, so I'll attach the respective PDF "prints" separately. Please note: the input file (.doc/ WordXP/ Word 2002) page size is custom (13cm x 21cm) and the PDF print on Debian does not preserve this, and provides (on my XFCE4 desktop) no option to set correct paper size - this used to work, but no longer; I shall file a separate bug report somewhere about this.
Created attachment 127047 [details] correct (MS Windows) pdf print output
Created attachment 127048 [details] incorrect output - LO pdf print on Debian
Note that the "incorrect" output, although I call it "output" is actually an incorrect conversion of the input document, and the incorrect conversion is seen within the LibreOffice writer as the (converted) document is displayed/ edited in LO. Happy to run tests, as well as test latest versions/ updates - I have a local libreoffice-core.git installation which I compile as needed; but the example output pdf files make the required result obvious anyway...
Please go ahead and post up a mockup in Writer .ODT of the layout working correctly in ODF.
Created attachment 127049 [details] example -correct- odt file/ transformation - works in LO 5.2.0.4 This works in LO 5.2.0.4. The transform should probably create a frame style in LO which has the same name as the corresponding para style in MSWord. That would be logical of course. As you can see, this .odt file looks very similar to the correct / successful (Word pdf print) output/ pdf print file. So, we can see that the LO frames engines can correctly support this marginalia style. I note that although it works, it is a recent functionality that it works at all - following is my attempt to load this (fixed) .odt file in Debian (stable) system LO installation: $ /usr/bin/soffice --version LibreOffice 4.3.3.2 430m0(Build:2) $ /usr/bin/soffice --writer submission-1-re-human-rights-fixed.odt error xsltParseStylesheetFile : cannot parse I/O warning : failed to load external entity "" error xsltParseStylesheetFile : cannot parse error xsltParseStylesheetFile : cannot parse I/O warning : failed to load external entity "" error xsltParseStylesheetFile : cannot parse error xsltParseStylesheetFile : cannot parse I/O warning : failed to load external entity "" error xsltParseStylesheetFile : cannot parse error xsltParseStylesheetFile : cannot parse I/O warning : failed to load external entity "" error xsltParseStylesheetFile : cannot parse error xsltParseStylesheetFile : cannot parse I/O warning : failed to load external entity "" error xsltParseStylesheetFile : cannot parse terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException' I will be very happy if this can be fixed in the current/ latest versions of LO, I have no attachment at all to the older version(s). :)
I hope this is a correct "mockup" - it uses frame style ("zenaanFrame") to do the job, which is the built in, if recent (to LO) functionality to get this type of text document layout working properly. I say this because when I hear the term "mockup" I think "totally fake Gimp image" or something :) It would be amusing to say the least, if a working LO writer file were not sufficient :D
Actually, the LO 4.3 failure seems to be that I can no longer run LO 4.3 at all - any idea how I can get it to run? I have Debian stable's LO 4.3 installed (/usr/...), LibreOffice 5.2.0.4 .deb distribution installed to /opt/libreoffice5.2 and moved to /opt/l/libreoffice5.2 , and LO 5.3 beta via .git compile, installed in $HOME/dev/locore.git/... and symlinked to /opt/l/libreoffice5.3/... $ echo $PATH /usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin $ /usr/bin/soffice terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'
I can confirm that submission-1-re-human-rights-fixed.odt can be loaded successfully in LO 5.3.0 beta as well. Enjoy :)
(In reply to Zenaan Harkness from comment #7) > Actually, the LO 4.3 failure seems to be that I can no longer run LO 4.3 at > all - any idea how I can get it to run? > > I have Debian stable's LO 4.3 installed (/usr/...), LibreOffice 5.2.0.4 .deb > distribution installed to /opt/libreoffice5.2 and moved to > /opt/l/libreoffice5.2 , and LO 5.3 beta via .git compile, installed in > $HOME/dev/locore.git/... and symlinked to /opt/l/libreoffice5.3/... > > $ echo $PATH > /usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin > $ /usr/bin/soffice > terminate called after throwing an instance of > 'com::sun::star::uno::DeploymentException' Have a read of the installing in parallel Wiki [1], you probably would want to separate the user profile location of the two installations. =-ref-= 1. https://wiki.documentfoundation.org/Installing_in_parallel/Linux
Thanks for posting the sample document in ODF. I only asked for a mock-up to see the means being used for structuring the "marginalia", having the complete document is perfect. So, yes confirming that using styled Text Frames anchored to paragraph allows this formatting in LO 5.2 and master (5.3)--however it is not imported from a MS Word 97-2003 binary file. Nor does Word 2007 correctly export them to ODF Text document .ODT format. More important is how this formatting behaves round trip from LibreOffice using export filter(s)--unfortunately we mishandle it as badly as does Word 2007. The placement of the Text frames (objects with zenaanFrame style) are anchored to paragraph--but the placement (0.08" from the Frame objects Position Horizontal "to Outer Paragraph border" w/mirror on even pages) and its AutoSize attribute is not filter parsed into the resulting 97-2003 MS Word binary, nor any of the XML based Word documents. On filter import back into LibreOffice, formatting for the Text Boxes is lost round trip.
(In reply to V Stuart Foote from comment #10) > The placement of the Text frames (objects with zenaanFrame style) are > anchored to paragraph--but the placement (0.08" from the Frame objects > Position Horizontal "to Outer Paragraph border" w/mirror on even pages) and > its AutoSize attribute is not filter parsed into the resulting 97-2003 MS > Word binary, nor any of the XML based Word documents. > > On filter import back into LibreOffice, formatting for the Text Boxes is > lost round trip. s/Text Boxes/Text Frames/g Of course layout of these "marginalia" are dealing with Writer's "Text frame" objects, and not the "Text box" shape Drawing objects.
This bug relates also to the following bug, to which I've added a fairly detailed description of an enhancement for LO which would help bring it up to par with WordXP functionality, and then further to take LO to a new level of functionality beyond WordXP. https://bugs.documentfoundation.org/show_bug.cgi?id=62071
Moving to LibreOffice filters & storage (ww8 import filter) rather than Document Liberation Project
The anchor of the Text Frame object holding "marginalia" annotation/reference is correctly place on import--but the position of the Frame relative to its anchor as defined in the MS Word binary or OOXML document is not retained. The Text Frame is imported at its anchor location.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.4.1 or 5.3.6 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170929
Dear Zenaan Harkness, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Dear Zenaan Harkness, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
repro 7.5+
repro 7.6+ anchored to "outside" of the page (i.e. right side, 0.2cm from the start of the right margin).
Created attachment 196074 [details] DOCX conversion by (MS) Office 365 much better import in LibreOffice, but frames are on the opposite margin
(In reply to László Németh from comment #20) > Created attachment 196074 [details] > DOCX conversion by (MS) Office 365 > > much better import in LibreOffice, but frames are on the opposite margin