[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [office] Forensics: Working with the ODF 1.1 ODT version
Hi Dennis, I had a closer look at the ODF 1.1 ODF document: The final version of this document has been created with StarOffice 8 PU2 - equivalent with OOo 2.0.2 - under operating system Solaris Sparc. The used fonts are different on Solaris compared to the ones under e.g. Windows. Thus, I think it will be very hard to find an ODF consumer for Windows which will show the same layout result as the StarOffice 8 PU2/OOo 2.0.2 under the used Solaris system. I opened the document with OOo 2.0.2 under Windows 7 64bit and got 723 pages. My conclusion is that we should not rely our erratas on page and line references - as you already said. Ad your reported table split defects: I opened this document with OOo 3.3 under Windows 7 64bit. I investigated all tables which split at the end of a page. I did not experience any of the defects which you have reported. I recall that there are defects in the layout algorithm of the one or the other OOo 2.x version regarding splitting tables. These has been fixed. Thus I suggest to use the lastest release, in case that you want to use OOo (or any of the alternatives which are based on OOo). Best regards, Oliver. On 28.03.2011 18:52, Dennis E. Hamilton wrote: > I have had an unexpected glitch in my wanting to start from the > editable ODF Text version of the OASIS ODF 1.1 Standard. The > versions of ODF consumers that I have do not match the pagination > that is shown in the PDF of the OASIS ODF 1.1 Standard. The > difference is substantial. The ODF consumers I have used all end up > with fewer pages (719 pages in OO.o 2.4.1, 720 pages in OO.o 3.2.0, > 718 pages in LibreOffice 3.3.2) instead of 738 pages in the PDFand it > appears to be related to how automatic page breaks are done. > > The screen capture illustrates the 1-page difference between OO.o > 2.4.1 and LOffice 3.3.2. In 2.4.1, section 9 is one page longer. > The creeping that ends up with one extra page begins in section 9.9 > in the page break just before the Event Effect subsection. (OO.o > 3.2.0 on a different machine has the break still different.) There > may have been other differences in page breaks before this, but none > of them changed the table of contents page numbers for any of the > indexed headings. > > As discussed on today's call, this is not a material problem for > creating an Errata 01 so long as we don't continue the practice of > the ODF 1.0 Errata 01 of using page and line numbers. I agree, we > can provide errata item description in a way that do not require page > and line references, and I had intended to do it that way. > > However, the problem with pagination differences is that I am then > left to wonder what else is being done differently. For that reason, > I would much prefer to use some sort of style or other adjustments to > have a pagination that is preserved in interchange among ODF > consumers and that leads to a matching PDF. > > In fact, in examining shorter pagination in a current ODF consumer, I > saw that some table breaks were being presented incorrectly. This is > apparently a bug in some consumers and I need to work around it. > (And this is why it is important to understand what the pagination > differences are all symptoms of and finding some way to mitigate > them.) > > - Dennis > > PS: Here are details of the bug as something to watch out for when > working on ODF TC specifications. I am not sure how to report it and > to whom, but here are the symptoms: > > 1. A table is split between two pages. The table is styled so that > table rows are not themselves split, and headings are also preserved > on continuation pages. > > 2. Sometimes, the table is split such that the last table row before > the split appears to have disappeared. > > 3. Apparently the last row retained before the split is there, but it > extends below the page body frame such that it is not visible. In > the case I observed, none of the clipped row was visible at all, but > it was observable that the top of another row was there (because the > vertical border lines of the table could be seen extending below the > last-visible row). > > 4. That's probably enough to figure out what the edge case is. Of > course, this bug is hard to report unless I capture a screen shot or > a PDF fragment that shows the incorrect presentation. If I see any > of those again I will capture screen shots. > > 5. There are other differences in how schema fragments are split > across pages. They can be cured by heavy-handed forcing of breaks > but not by anything I've been able to do by adjusting styling or page > parameters (footer distance for example). (I notice that the jitter > between schema fragment lines is also present but not always exactly > the same compare do the original.) > > 6. Just to demonstrate that I am not picking on the OO.o code base > alone, I also opened the ODF 1.1 standard in Microsoft Office 2010 > Word and got an even shorter document, although updating the table of > contents makes it almost match the PDF in terms of the last page > number, but only because the TOC blew up to where it ended on page 60 > of 739. The Office 2010 version is not useable for my purposes > because of other formatting discrepancies, especially for the schema > fragments. > > PPS: I can imagine that there is something about lining up the pixels > and font rendering that leads to these discrepancies of pagination, > even though I have the same default printer in all cases. (But > Windows 7 doesn't use the printer manufacturer's drivers any longer.) > As David Wheeler mentioned on the call, these variations are > well-known. My problem is that I can't tell whether the deviations > hide more-material discrepancies such as defects in inter-page table > splitting. This also is what has bothered me about having the > editable form as the authoritative edition. There is no assurance > that different users will see the same authoritative text. I think > fidelity should trump reusability and I have no evidence that the PDF > renditions of these documents are worse in interchange than what I am > seeing here. > > -----Original Message----- From: Dennis E. Hamilton > [mailto:dennis.hamilton@acm.org] Sent: Sunday, March 27, 2011 16:25 > To: 'ODF TC List ' Cc: 'Michael Brauer '; 'Patrick Durusau '; > robert_weir@us.ibm.com; 'Robin Cover' Subject: [office] Working Draft > for ODF 1.1 (Second Edition)? > > As part of compiling ODF 1.1 Errata 01, I will be making a > change-marked version of the OASIS ODF 1.1 Specification, reflecting > the change that is needed to reflect the ODF 1.0 Errata 02 plus the > IS 26300 COR1, COR2, and AMD1 (where they have deviations we must > anticipate). > > My intention is to use those change-markings as the basis for the > individual ODF 1.1 Errata 01 instructions. I find this to be the > most-reliable way to go about this. > > [ ... ] > > > > --------------------------------------------------------------------- > > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- > ORACLE http://www.oracle.com Oliver-Rainer Wittmann | Oracle Open Office and ODF Standardization Phone: +49 40 23646 500 Oracle Office GBU ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRA 95603 Komplementärin: ORACLE Deutschland Verwaltung B.V. Rijnzathe 6, 3454PV De Meern, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Geschäftsführer: Jürgen Kunz, Marcel van de Molen, Alexander van der Ven http://www.oracle.com/commitment Oracle is committed to developing practices and products that help protect the environment
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]