Version: 1.0.2 (using KDE 3.2.3, (testing/unstable)) Compiler: gcc version 3.3.3 (Debian 20040422) OS: Linux (i686) release 2.6.7-1-686 Then saving eps kolourpaint sets incorect bounding box.
Seems to be correct for large images (1024x768) but wrong for small ones (e.g. 200x160). Reassigning to KImageIO.
Is Kolourpaint using Qt's PostScript and perhaps "custom" pages? If yes... it is a Qt bug... Have a nice day!
Well, EPS kimgio does not even set a page size, so indeed it will be always the default size, which is ISO A4. Also it tries to make an extra boundix box with the size of the image. (I am not sure that it works.) As for how to solve this, I do not know, as it is one of the problems of KOffice, espcially of KChart. (I suppose that there must even be a bug report.) Have a nice day!
On Fri, 16 Jul 2004 02:18 am, Nicolas Goutte wrote: > Is Kolourpaint using Qt's PostScript and perhaps "custom" pages? > Sorry, I don't understand your question. KolourPaint has basically the following code: ~~~ KPrinter printer; printer.setup (this); QPainter painter; painter.begin (&printer); painter.drawPixmap (0, 0, thePixmap); painter.end (); ~~~
So the answer is yes. You are using Qt's PostScript generation. As for "custom", any page size not defined in Qt's QPrinter (including the "custom" size) does not work, as you cannot set the page size. Have a nice day!
On Fri, 16 Jul 2004 05:16 pm, Nicolas Goutte wrote: > As for "custom", any page size not defined in Qt's QPrinter (including the > "custom" size) does not work, as you cannot set the page size. > So is there anything I can do on the KolourPaint end? Thanks, Clarence
Could one of you attach one of the generated EPS file? I would like to see how it is. (I am sorry I have not KDE CVS HEAD and especially not Kolourpaint, so I am not sure how to generate such a file with Kimgio.) Have a nice day!
To comment #6: By using Qt, no, I do not think of. If there would be a solution, I would be very interested in it, as it matters KOffice too. As for the exact problem, they might be one. It would be to generate the PostScript code directly as anyway the source is only a picture. (Not sure if it should be in Kolourpaint however. I suppose that it should be in the Kimgio write plugin instead.) Have a nice day!
On Fri, 16 Jul 2004 05:27 pm, Nicolas Goutte wrote: > Could one of you attach one of the generated EPS file? The attached EPS what I get after saving the attached PNG. Created an attachment (id=6692) kde_with_colours.eps Created an attachment (id=6693) kde_with_colours.png
On Fri, 16 Jul 2004 05:30 pm, Nicolas Goutte wrote: > As for the exact problem, they might be one. It would be to generate the > PostScript code directly as anyway the source is only a picture. Yes, I think you're right. It would also fix the currently painful speed of the EPS filter (it appears to invoke ghostscript). > (Not sure if it should be in Kolourpaint however. I suppose that it should > be in the Kimgio write plugin instead.) Yes, the plugin should be fixed.
Thank you! It is exactly what I had suspected. The generated file is just a PS file and not an EPS at all. (It also calls showpage, which is a no-no for an EPS file.) So I suppose that this code once work, once upon a time when Qt generated EPS for one page documents. However Qt does not do that anymore... Have a nice day! On Friday 16 July 2004 09:38, Clarence Dang wrote: (...) > On Fri, 16 Jul 2004 05:27 pm, Nicolas Goutte wrote: > > Could one of you attach one of the generated EPS file? > > The attached EPS what I get after saving the attached PNG. > > > Created an attachment (id=6692) > --> (http://bugs.kde.org/attachment.cgi?id=6692&action=view) > kde_with_colours.eps > > Created an attachment (id=6693) > --> (http://bugs.kde.org/attachment.cgi?id=6693&action=view) > kde_with_colours.png
On Friday 16 July 2004 09:42, Clarence Dang wrote: (...) > On Fri, 16 Jul 2004 05:30 pm, Nicolas Goutte wrote: > > As for the exact problem, they might be one. It would be to generate the > > PostScript code directly as anyway the source is only a picture. > > Yes, I think you're right. It would also fix the currently painful speed > of the EPS filter (it appears to invoke ghostscript). Well, it uses GhostScript only at load and that is not going to change. :-( As for writing, I thought about using GhostScript to convert it to an EPS file (script ps2epsi) but the showpage command remains called in the changed file, so the generated file is not a true EPS file either. So it is not an option. (...)
This being a kimgio bug, I suggest that you start using the eps kimgio output filter first then, just report it here if that one has bugs so that we can fix it. From quick inspection it doesn't seem to do the bounding box right.
On Friday 16 July 2004 11:44, Waldo Bastian wrote: (...) > This being a kimgio bug, I suggest that you start using the eps kimgio > output filter first then, just report it here if that one has bugs so that > we can fix it. From quick inspection it doesn't seem to do the bounding box > right. Yes, it has bugs. That is what I am seeing looking at the code. (See my previous comments, for example the one about not creating an EPS file but a PS one.) Have a nice day!
Oh, wait... I misunderstood comment #4, I thought that the code quoted there was part of kolourpaint, but I now understand that that is effectively the code that kimgio uses. I just notice that Qt 3.3 can actually generate eps files itself, see qpsprinter.cpp: if ( finished && pageCount == 1 && printer->numCopies() == 1 && ( ( printer->fullPage() && qt_gen_epsf ) || ( printer->outputToFile() && printer->outputFileName().endsWith( ".eps" ) ) ) ) { if ( !boundingBox.isValid() ) boundingBox.setRect( 0, 0, width, height ); It seems that the boundingBox is derived from the clipping of the painter
On Fri, 16 Jul 2004 08:55 pm, Waldo Bastian wrote: > Oh, wait... I misunderstood comment #4, I thought that the code quoted > there was part of kolourpaint Actually, that code is part of kolourpaint - it's just that I now realised that I posted the wrong code snipplet (printing instead of saving). What I meant to say is that I have very generic saving code that passes the image to KImageIO and so the bug is in kdelibs/kimgio/eps.cpp. So I guess I am the source of the confusion :)
CVS commit by waba: Fix EPS generation. (BR85217) CCMAIL: 85217-done@bugs.kde.org M +7 -14 eps.cpp 1.25 --- kdelibs/kimgio/eps.cpp #1.24:1.25 @@ -248,5 +248,5 @@ void kimgio_eps_read (QImageIO *image) void kimgio_eps_write( QImageIO *imageio ) { - QPrinter psOut; + QPrinter psOut(QPrinter::PrinterResolution); QPainter p; @@ -255,5 +255,6 @@ void kimgio_eps_write( QImageIO *imageio psOut.setOutputToFile( true ); - KTempFile tmpFile; + // Extension must be .eps so that Qt generates EPS file + KTempFile tmpFile(QString::null, ".eps"); tmpFile.setAutoDelete(true); if ( tmpFile.status() != 0) @@ -262,21 +263,15 @@ void kimgio_eps_write( QImageIO *imageio psOut.setOutputFileName(tmpFile.name()); + psOut.setFullPage(true); // painting the pixmap to the "printer" which is a file p.begin( &psOut ); - - p.translate( -36, 820 - imageio->image().height() ); - + // Qt uses the clip rect for the bounding box + p.setClipRect( 0, 0, imageio->image().width(), imageio->image().height(), QPainter::CoordPainter); p.drawImage( QPoint( 0, 0 ), imageio->image() ); p.end(); - // write BoundingBox to File + // Copy file to imageio struct QFile inFile(tmpFile.name()); - QString szBoxInfo; - - szBoxInfo.sprintf("%%%%BoundingBox: 0 0 %d %d\n", - imageio->image().width(), - imageio->image().height()); - inFile.open( IO_ReadOnly ); @@ -288,5 +283,4 @@ void kimgio_eps_write( QImageIO *imageio QString szInLine = in.readLine(); out << szInLine << '\n'; - out << szBoxInfo; while( !in.atEnd() ){
On Fri, 16 Jul 2004 09:21 pm, Waldo Bastian wrote: > CVS commit by waba: > > Fix EPS generation. (BR85217) That was fast; EPS write works great now, thanks :)
This bug has reappeared (using KDE4.2). After images are saved as EPS, they are always 595x842 no matter what size they were before. This also happens in Gwenview when I convert a JPG or PNG file to EPS.
I can confirm that the problem is here again (KDE 4.9.0, Qt 4.8.2). I suspect the reason is that since this original report a lot has changed in Qt (as we're already on Qt4). Still, I think I have a bugfix and will submit a review request
Git commit 0fb5da54e7fd430d64d881fdf8427075df5a76a4 by Martin Koller. Committed on 31/08/2012 at 20:08. Pushed by mkoller into branch 'KDE/4.9'. fix bounding box in writing A very old bug reappeared. Obviously Qt internals have changed since then. FIXED-IN: 4.9.2 REVIEW: 106290 M +1 -2 kimgio/eps.cpp http://commits.kde.org/kdelibs/0fb5da54e7fd430d64d881fdf8427075df5a76a4