Version: 0.5.94 (using KDE 3.97.1 (KDE 4.0 >= 20071214), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.22-14-generic File Prova.odt is bad rendered, text in a table is not aligned (Left, Right, Center), every line is mixed with the others, the table is not displayed in all its length and this way numbered lists are not shown. Everything is a mess. Look by yourself. shot1.png good OOo-Writer rendering shot2.png bad Okular rendering
Created attachment 22801 [details] Example file
Created attachment 22802 [details] Good rendering
Created attachment 22803 [details] Very bad rendering
Version 0.7 Using KDE 4.1.1 (KDE 4.1.0 (4.1 >= 20080722)) (KDEmod) in ArchLinux i686: I can confirm this bug in rendering
This bug still happens on KDE 4.1.3 and KDE4.2svn (kdegraphics rev. 890639). Here is some shell output: [dario@emiDell Desktop]$ okular Prova.odt okular(11584)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to open ksycoca from "/var/tmp/kdecache-dario/ksycoca4" okular(11584)/kio (KDirWatch) KDirWatchPrivate::KDirWatchPrivate: Available methods: ("Stat", "INotify") okular(11584)/kparts KParts::MainWindow::createGUI: MainWindow::createGUI, part= Part(0xf941c0) Part "" okular(11584)/kdecore (trader) KMimeTypeTrader::query: query for mimeType "application/vnd.oasis.opendocument.text" , "okular/Generator" : returning 1 offers okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 okular(11584)/KZip KZip::openArchive: trying to seek for next PK78 unknown tag table-properties unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown unit unknown tag graphic-properties unknown tag table-properties unknown tag table-row-properties unknown tag outline-style unknown tag notes-configuration unknown tag notes-configuration unknown tag linenumbering-configuration unknown tag default-page-layout I wonder if all the "unknown" lines have something to do with this bug / strange odt file.
I can still reproduce it using: Qt: 4.4.3 KDE: 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)) kdelibs svn rev. 896844 / kdebase svn rev. 896844 kdegraphics svn rev. 896874 Confirming.
@Darío Andrés: please use the "testcase" keyword.
I've started looking at this bug. There is more than one missing element involved. 1. We aren't handling the different alignment of elements within a single cell. So the first cell in the second row should render something like: BOH MAH CHI LO SA But we render it as CHI LO SAMAHBOH (with some wordwrapping) That is caused partly by inserting text at the beginning position (cell.firstCursorPosition(), which is easily fixed) and partly by not being able to set the alignment as a text property, only as a block property. The only way I can see of resolving this is to insert invisible frames within the cell, one for each <p> block. while ( !paragraphElement.isNull() ) { if ( paragraphElement.tagName() == QLatin1String( "p" ) ) { QTextTableCell cell = table->cellAt( rowCounter, columnCounter ); - QTextCursor cursor = cell.firstCursorPosition(); - cursor.setBlockFormat( format ); + // Insert a frame into the cell and work on that, so we can handle + // different parts of the cell having different block formatting + QTextCursor cellCursor = cell.lastCursorPosition(); + QTextFrame *frame = cellCursor.insertFrame( QTextFrameFormat() ); + QTextCursor frameCursor = frame->firstCursorPosition(); + frameCursor.setBlockFormat( format ); - if ( !convertParagraph( &cursor, paragraphElement, format ) ) + if ( !convertParagraph( &frameCursor, paragraphElement, format ) ) return false; } 2. We don't support the start, end and justify alignment types. A temporary hack to fix that: --- styleparser.cpp (revision 903994) +++ styleparser.cpp (working copy) @@ -291,6 +291,9 @@ alignMap.insert( "center", Qt::AlignCenter ); alignMap.insert( "left", Qt::AlignLeft ); alignMap.insert( "right", Qt::AlignRight ); + alignMap.insert( "justify", Qt::AlignJustify ); + alignMap.insert( "start", Qt::AlignLeft ); // TODO: fix for RL writing mode + alignMap.insert( "end", Qt::AlignRight ); // TODO: fix for LR writing mode } if ( parent.hasAttribute( "text-align" ) ) { property.setTextAlignment( alignMap[ parent.attribute( "text-align", "left" ) ] ); 3. We don't properly size the cells / columns. Need to parse the table-column attributes, and find a way to map that into a Qt property. Presumably that will require some kind of call to tableFormat.setColumnWidthConstraints(). 4. We don't support lists. Need to support the parsing and list styles. I have part of this done, and can look at the rest. Question for Pino - is this really a bug fix (i.e. 4.2) or an enhancement (i.e. 4.3)? It certainly could introduce regressions...
SVN commit 905238 by bhards: Add support for the "justify", "start" and "end" text alignment modes. Partly addresses rendering problems identified at http://bugs.kde.org/show_bug.cgi?id=154980 CCBUG:154980 M +5 -0 formatproperty.cpp M +2 -0 formatproperty.h M +9 -0 styleparser.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=905238
SVN commit 906395 by bhards: General improvements to visual rendering of .odt documents. We can now (more) correctly render cell widths, documents containing more than just a table, documents containing lists within table cells, and documents containing variable formatting within a single table cell. Significantly improves rendering of example in http://bugs.kde.org/show_bug.cgi?id=154980 There is still an issue relating to list indenting. CCBUG:154980. M +33 -14 converter.cpp M +1 -1 converter.h M +5 -1 formatproperty.cpp M +1 -0 formatproperty.h WebSVN link: http://websvn.kde.org/?view=rev&revision=906395
SVN commit 907544 by bhards: Implement support for the left-margin property. This completes the work on the test sample in http://bugs.kde.org/show_bug.cgi?id=154980 BUG:154980 M +7 -0 formatproperty.cpp M +2 -0 formatproperty.h M +6 -0 styleparser.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=907544