Version: (using KDE Devel) Installed from: Compiled sources OS: Linux Copied from koffice-devel: I'm opening the file kofficetests/documents/import/mswrite/filtertest.wri (no this isn't a plug to make you test the new mswriteimport filter because I haven't uploaded it yet :)) and exporting to RTF: 3. It can't handle the B&W bitmap found on page 438 (don't be scared, the document is actually only 5 pages long :)) If you open the exported RTF, the BMP appears as a black blob in OOo
What I have found so far: - AbiWord's RTF import can read it correctly - KWord's RTF import filter cannot (not even when forced to a PNG) Have a nice day/evening/night!
With the help of KWord 1.2-SuSE 8.1 and koconverter CVS HEAD, I have found out that both RTF import filters can correctly read the picture. So now we have following problems: - is there a bug in KWord CVS HEAD for pictures? - does OO not work because of the problem with the ASCII art happening before the picture?
Clarence, did you have this bug while re-importing in KWord or by trying to import it in OOWriter? If it is with OOWriter, could you please test this image alone in a document? As for me, after fixing bug #52661, the image loads back correctly in KWord now. Have a nice day/evening/night!
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Thu, 9 Jan 2003 09:44 pm, Nicolas Goutte wrote: > Clarence, did you have this bug while re-importing in KWord No, it works fine with KWord RTF import. It's just that when I was testing RTF export I used oowriter's RTF import because OOo is supposed to have the best filters... > or by > trying to import it in OOWriter? > Yes. > If it is with OOWriter, could you please test this image alone in a > document? > Ok, I tested it alone but OOWriter still displays it as a black blob. I would be tempted to say that this is an OOo bug but the image does not show up in Wordpad (Win98) nor Word97. Clarence
Then there is really a problem in the picture export. Sigh! Could you please try to edit the RTF file with an editor (for example Kate) and replace \wbitmap by \dibitmap ? (I do not know if it so simple but we need to try.) Have a nice day/evening/night!
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Mon, 13 Jan 2003 12:46 am, Nicolas Goutte wrote: > Could you please try to edit the RTF file with an editor (for example Kate) > and replace \wbitmap by \dibitmap ? (I do not know if it so simple but we > need to try.) > Ok, it seems that I'm staying on the internet for longer than I anticipated so I've managed to test it: OOo can now read it! The \dibitmap fix works! I'll check in Windows (Word97) later though just to make sure. Clarence
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Mon, 13 Jan 2003 03:22 am, Clarence Dang wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=52725 > > > > > ------- Additional Comments From dang@kde.org 2003-01-13 04:22 ------- > Subject: Re: monochrome BMP not exported properly by KWord's RTF filter > > On Mon, 13 Jan 2003 12:46 am, Nicolas Goutte wrote: > > Could you please try to edit the RTF file with an editor (for example > > Kate) and replace \wbitmap by \dibitmap ? (I do not know if it so simple > > but we need to try.) > > Ok, it seems that I'm staying on the internet for longer than I anticipated > so I've managed to test it: > > OOo can now read it! The \dibitmap fix works! > I'll check in Windows (Word97) later though just to make sure. > Bad news: It still doesn't import the bitmap in Word97 :( Clarence
It is a OO problem. See issue #2244 http://www.openoffice.org/issues/show_bug.cgi?id=2244 and issue #2165 http://www.openoffice.org/issues/show_bug.cgi?id=2165 Have a nice day/evening/night!
Sorry, I am plain wrong. We have still the MS Word issue... However, I would really like to know the difference between \wbitmap and \dibitmap before changing it.
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Mon, 13 Jan 2003 06:37 pm, Nicolas Goutte wrote: > ------- Sorry, I am plain wrong. We have still the MS Word issue... > > However, I would really like to know the difference between \wbitmap and > \dibitmap before changing it. Wow, look at what Word97 generated (attachment). Some very strange stuff in there. Created an attachment (id=756) bmp30.rtf
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter Yes, that is how MS Word 97's RTF works. It put everything in a metafile. But I suppose that it supports BMP too, as old MS Word versions did write it. The problem is just to know what we are missing. (I have a little idea but not the time to code it.) Have a nice day/evening/night! On Thursday 16 January 2003 05:57, Clarence Dang wrote: > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=52725 > > > > > ------- Additional Comments From dang@kde.org 2003-01-16 05:57 ------- > Subject: Re: monochrome BMP not exported properly by KWord's RTF filter > > On Mon, 13 Jan 2003 06:37 pm, Nicolas Goutte wrote: > > ------- Sorry, I am plain wrong. We have still the MS Word issue... > > > > However, I would really like to know the difference between \wbitmap and > > \dibitmap before changing it. > > Wow, look at what Word97 generated (attachment). > Some very strange stuff in there. > > > > Created an attachment (id=756) > --> (http://bugs.kde.org/attachment.cgi?id=756&action=view) > bmp30.rtf
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Thu, 16 Jan 2003 06:58 pm, Nicolas Goutte wrote: > Yes, that is how MS Word 97's RTF works. It put everything in a metafile. > > > > ------- Additional Comments From dang@kde.org 2003-01-16 05:57 ------- > > > > Wow, look at what Word97 generated (attachment). > > Some very strange stuff in there. > > What I mean is: there appears to be 2 images in there (yet in the original file wmf30.wri, there is only 1)! One of them is the real one and the other is the inverse! Yet both Word97 and OOo open it correctly (?) as a single image while KWord's RTF import does not. Perhaps you are supposed to save 2 images instead of 1 (wild guess)?
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter Could you convert the image to a PNG and see if a PNG image makes as much problems? I mean: does exporting a PNG from KWord to MS Word work or does it have similar problems? Have a nice day/evening/night! On Thursday 23 January 2003 06:09, Clarence Dang wrote: (...) > ------- Additional Comments From dang@kde.org 2003-01-23 06:09 ------- > Subject: Re: monochrome BMP not exported properly by KWord's RTF filter > > On Thu, 16 Jan 2003 06:58 pm, Nicolas Goutte wrote: > > Yes, that is how MS Word 97's RTF works. It put everything in a metafile. > > > > > ------- Additional Comments From dang@kde.org 2003-01-16 05:57 ------- > > > > > > Wow, look at what Word97 generated (attachment). > > > Some very strange stuff in there. > > What I mean is: there appears to be 2 images in there (yet in the original > file wmf30.wri, there is only 1)! One of them is the real one and the > other is the inverse! Yet both Word97 and OOo open it correctly (?) as a > single image while KWord's RTF import does not. Perhaps you are supposed > to save 2 images instead of 1 (wild guess)?
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Thu, 23 Jan 2003 10:38 pm, Nicolas Goutte wrote: > ------- Subject: Re: monochrome BMP not exported properly by KWord's RTF filter > > Could you convert the image to a PNG and see if a PNG image makes as much > problems? > > I mean: does exporting a PNG from KWord to MS Word work or does it have > similar problems? > Sorry, I don't quite understand what you mean. But I have done two tests to cover both interpretations of your request: 1. I converted the BMP to a PNG (using GIMP) and inserted the PNG in KWord (for some reason it displayed it inverted!) and then I saved it to RTF. The RTF opened fine in Word97 and wasn't inverted. 2. I inserted the PNG into Word97 and saved to RTF. There are 2 {\pict tags in the RTF file but the KWord RTF Importer reads it properly as a single image. Thanks, Clarence > > ------- Additional Comments From dang@kde.org 2003-01-23 06:09 ------- > > Subject: Re: monochrome BMP not exported properly by KWord's RTF filter > > > > On Thu, 16 Jan 2003 06:58 pm, Nicolas Goutte wrote: > > > Yes, that is how MS Word 97's RTF works. It put everything in a > > > metafile. > > > > > > > ------- Additional Comments From dang@kde.org 2003-01-16 05:57 > > > > ------- > > > > > > > > Wow, look at what Word97 generated (attachment). > > > > Some very strange stuff in there. > > > > What I mean is: there appears to be 2 images in there (yet in the > > original file wmf30.wri, there is only 1)! One of them is the real one > > and the other is the inverse! Yet both Word97 and OOo open it correctly > > (?) as a single image while KWord's RTF import does not. Perhaps you are > > supposed to save 2 images instead of 1 (wild guess)?
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Friday 24 January 2003 11:20, Clarence Dang wrote: (...) > On Thu, 23 Jan 2003 10:38 pm, Nicolas Goutte wrote: (...) > > 1. I converted the BMP to a PNG (using GIMP) and inserted the PNG in KWord > (for some reason it displayed it inverted!) and then I saved it to RTF. > The RTF opened fine in Word97 and wasn't inverted. I can reproduce the inverted problem. (Sigh! Again a bug!) > > 2. I inserted the PNG into Word97 and saved to RTF. There are 2 {\pict > tags in the RTF file but the KWord RTF Importer reads it properly as a > single image. Yes, but MS Word generates normally 2 WMF streams ( \wmetafile8 .) Or does it has really generated at least a PNG ( \pngblip ) > > Thanks, > Clarence Have a nice day/evening/night! (...)
Subject: Re: monochrome BMP not exported properly by KWord's RTF filter On Sun, 26 Jan 2003 01:20 am, Nicolas Goutte wrote: > On Friday 24 January 2003 11:20, Clarence Dang wrote: > > 2. I inserted the PNG into Word97 and saved to RTF. There are 2 {\pict > > tags in the RTF file but the KWord RTF Importer reads it properly as a > > single image. > > Yes, but MS Word generates normally 2 WMF streams ( \wmetafile8 .) Or does > it has really generated at least a PNG ( \pngblip ) > One {\pict with \pngblip... followed by one {\pict with \wmetafile8 Clarence
Subject: koffice/filters/kword/rtf/export CVS commit by goutte: Disable exporting of BMP files in RTF (convert to PNG) Reason: BMP are not exported correctly. (This is provisory for KOffice 1.3.) CCMAIL:52725@bugs.kde.org CCMAIL:koffice-devel@kde.org M +7 -5 ExportFilter.cc 2.57 --- koffice/filters/kword/rtf/export/ExportFilter.cc #2.56:2.57 @@ -121,8 +121,10 @@ bool RTFWorker::makeImage(const FrameAnc QString strTag; - if (strExt=="bmp") - strTag="\\dibitmap"; - else if (strExt=="png") + if (strExt=="png") strTag="\\pngblip"; +#if 0 + else if (strExt=="bmp") + strTag="\\dibitmap"; +#endif else if ( (strExt=="jpeg") || (strExt=="jpg") ) strTag="\\jpegblip";
Subject: koffice/lib/kofficecore CVS commit by goutte: Do not show monochrome images (color-) reversed CCMAIL:30357-close@bugs.kde.org CCMAIL:52725@bugs.kde.org M +2 -2 koPictureImage.cc 1.20 --- koffice/lib/kofficecore/koPictureImage.cc #1.19:1.20 @@ -79,10 +79,10 @@ void KoPictureImage::scaleAndCreatePixma if ( fastMode ) { - m_cachedPixmap = m_originalImage.scale( size ); + m_cachedPixmap.convertFromImage(m_originalImage.scale( size ), QPixmap::Color); // Always color or else B/W can be reversed m_cacheIsInFastMode=true; } else { - m_cachedPixmap = m_originalImage.smoothScale( size ); + m_cachedPixmap.convertFromImage(m_originalImage.smoothScale( size ), QPixmap::Color); // Always color or else B/W can be reversed m_cacheIsInFastMode=false; }
Subject: koffice/filters/kword/rtf/import CVS commit by goutte: Fix RTF's "shape pictures". (Two pictures were displayed because the filter read the shape picture and its replacement picture, which is for non-shape-picture-aware RTF readers only.) CCMAIL:52725@bugs.kde.org M +16 -3 rtfimport.cpp 1.62 M +2 -0 rtfimport.h 1.22 --- koffice/filters/kword/rtf/import/rtfimport.cpp #1.61:1.62 @@ -58,9 +58,10 @@ static RTFProperty propertyTable[] = MEMBER( "@rtf", "@headerl", parseRichText, oddPagesHeader, true ), MEMBER( "@rtf", "@headerr", parseRichText, evenPagesHeader, true ), - PROP( "@rtf", "@info", skipGroup, 0L, true ), - PROP( "Text", "@shpinst", skipGroup, 0L, true ), + PROP( "@rtf", "@info", parseGroup, 0L, true ), + PROP( "Text", "@nonshppict", skipGroup, 0L, false ), PROP( "Text", "@pict", parsePicture, 0L, true ), MEMBER( "@", "@rtf", parseRichText, bodyText, true ), - PROP( "Text", "@shppict", skipGroup, 0L, false ), + PROP( "Text", "@shpinst", skipGroup, 0L, true ), + PROP( "Text", "@shppict", parseGroup, 0L, false ), PROP( "@rtf", "@stylesheet", parseStyleSheet, 0L, true ), MEMBER( "@info", "@title", parsePlainText, title, false ), @@ -351,4 +352,5 @@ KoFilter::ConversionStatus RTFImport::co emptyCell = state.tableCell; state.format.uc=1; + state.ignoreGroup = false; // Parse RTF document @@ -1230,4 +1232,7 @@ void RTFImport::parseColorTable( RTFProp void RTFImport::parsePicture( RTFProperty * ) { + if (state.ignoreGroup) + return; + if (token.type == RTFTokenizer::OpenGroup) { @@ -1734,8 +1739,16 @@ void RTFImport::parsePlainText( RTFPrope /** + * Do nothing special for this group + */ +void RTFImport::parseGroup( RTFProperty * ) +{ +} + +/** * Discard all tokens until the current group is closed. */ void RTFImport::skipGroup( RTFProperty * ) { + state.ignoreGroup = true; } --- koffice/filters/kword/rtf/import/rtfimport.h #1.21:1.22 @@ -203,4 +203,5 @@ struct RTFGroupState RTFSectionLayout section; bool brace0; // '}' will close the current destination + bool ignoreGroup; // Should the group be ignored? }; @@ -252,4 +253,5 @@ public: void parseRichText( RTFProperty * ); void parsePlainText( RTFProperty * ); + void parseGroup( RTFProperty * ); void skipGroup( RTFProperty * ); void changeDestination( RTFProperty *property );
A bug this old, with the maintainer moved on so, lets close it as long as nobody is re-reporting it.