Version: 1.3.0 (using KDE KDE 3.4.2) Installed from: Mandriva RPMs When printing a graphic-file, there are the options to 1. enlarge the printout of smaller graphics to fit in page 2. downsize the printout of bigger graphics to fit in page 3. use no scaling at all For option 3.) the DPI-information stored in the graphic-file should be used - but it doesn't! I've made a sample PNG-file which should be printed in size 15cmx20cm. The Gimp does print-out the file correctly - Gwenwiew tells me that it wouldn't fit on a DINA4-page when "no scaling at printout" is selected!!!
Created attachment 16812 [details] Sample PNG-file - Size: 15cmx20cm
Can you test curent svn? I should have fixed it.
> Can you test curent svn? I should have fixed it. Unfortunately I don't have the skills to compile a SVN-version myself. I'll have to wait until GwenView will be released in a new version and maybe then someone is willing to build it for my distro. Wow - thank you in advance! Now GwenView would be the 1st KDE-program beside "Kolourpaint" being able to print pictures in correct sizes. Almost unbelievable but true. Maybe you want to vote for the similar bugs in other picture-related software, too: kooka: http://bugs.kde.org/show_bug.cgi?id=129641 or http://bugs.kde.org/show_bug.cgi?id=119110 showfoto: http://bugs.kde.org/show_bug.cgi?id=131582 kuickshow: http://bugs.kde.org/show_bug.cgi?id=84002
Alle 13:53, venerdì 19 gennaio 2007, MaxiPunkt ha scritto: [bugs.kde.org quoted mail] Ehm reading that you make me think I'm not sure i did what you expetcted to have. I'll try your picture soon to be sure. To be honest I should have fixed the scale option and IIRC the option 2 by now. If you try using scale option (with keeping ratio enabled) it should take care of dpi original ratio. Which the version you're using now?
Well I've just tested it following the steps below using gwenview 1.4.1 patched by me to have last svn commits (rebuilt srpms for mandriva 2007 from mandriva cooker): 1) page set to a4 (I don't have any ones different unfortunately) 2) option set to fit to page and enlarge smaller.... the output is printed and fitted on my a4 page 1) page is always a4 2) chosen scale to 15cm and keep ratio enabled put h to 19,99cm the output is printed and it is 15x20 cm inside my a4 page. Hope that is what you need to, let me know. Angelo
Now I'm using GwenView v. 1.4.0 > If you try using scale option (with keeping ratio enabled) it should take care of dpi original ratio. If I choose the scale-option, there is only the possibility to define the printout-size in mm, cm, or inch. So this has nothing to do with the dpi-information inside the graphics-file at all! Let's say we have this graphics-file I've uploaded as an attachment. It has a physical resolution of 1.772 x 2.362 pixel Beside this there is the information inside the png-file that it has a resolution of 300dpi. With exactly this information the printout-sizes can be calculated: => Width : 1.772 Pixel / 300dpi * 2,54 = 15,0cm (5,91") => Length: 2.362 Pixel / 300dpi * 2,54 = 20,0cm (7,87") If I print this file with no scaling enabeled, it should be printed out automaticly at size 15x20cm by using the information 300dpi. Also there should be an option to chose the printout size in percent related to the original printout-size (which isn't present in the GwenView-version I'm using), and GwenView should always calculate the printout-size then by using the additional information of these 300dpi - if present. 100% => 15 x 20 cm 50% => 7,5 x 10 cm 150% => 22,5 x 30cm ... and so on. This is how it's done F O R Y E A R S in MS-Windows programs - just have a look at XnView or IrfanView or something similar. I simply don't want to be forced to calculate the printout-sizes of images by hand and type them in manually in the scale-menu of GwenView. But this is how it has to be done in almost all KDE-programs I know of. Just imagine I do a scan with XSane, save the file somewhere and want to printout it later - of course the printout should be at the same size as the master. XSane does store dpi-information in all the common graphic-files (png, tiff, jpg). I don't know why this dpi-information can't be used with most of present Linux-programs (especially KDE), seem's that noone thought about such a simple need. The scan-program kooka even isn't able to save the dpi-information of a scanned image - it's just unbelievable for me => you aren't able to do 1:1 copies with kooka!
> chosen scale to 15cm and keep ratio enabled put h to 19,99cm No - this is not what I want to have: Let's say I send you a graphics-file of a scanned image holding the dpi-information with which resolution it was scanned. How can you do a 1:1 printout of it with GwenView - without knowing it's original size?? It's not practical at all to have to define the printout sizes in mm or cm in this case! With MS-Windows programs I can printout any graphics-file by choosing the option "100%" and it will be printed in exacly the size of the master. I don't have to think about dpi-values, nor printout-sizes - it is all done automaticly by using the WHOLE informations inside the file! Do you understand what I mean?
Just to show you how things should work: * Download the PNG-file I've attached, * Open a new document in Open Office Writer * paste the downloaded graphics-file in the OO-document * look at the size of the image And now think about why OpenOffice "knows" its size of exactly 15x20cm! You don't have to define no image-sizes at all - because it already IS defined INSIDE the file. This is what GwenView still has to learn. Btw. with the MS-Windows-programs like IrfanView or XnView you can also "tweak" the dpi-values of an image (a feature GwenView doesn't provide, also). This doesn't change not one pixel of the image (the resolution of 1.772 x 2.362 pixel will be kept), but the printout-size of the picture.
Alle 16:49, venerdì 19 gennaio 2007, MaxiPunkt ha scritto: [bugs.kde.org quoted mail] you can download a new version from gv site if you like, not with svn patch of course. It is packaged by me (who is also official packager and maintainer for mandriva) > > If you try using scale option (with keeping ratio enabled) it should take care of dpi original ratio. > If I choose the scale-option, there is only the possibility to define the printout-size in mm, cm, or inch. That is, if i'm not wrong, the only you can have, you should think that your printer could be set to print to 600dpi for instance. > => Width : 1.772 Pixel / 300dpi * 2,54 = 15,0cm (5,91") > => Length: 2.362 Pixel / 300dpi * 2,54 = 20,0cm (7,87") But the dpi we use are the one set into printer so if you want to have a 15x20 cm pictures and keep the ratio, i need to know the pixels and the printer dpi settings. So (even if 1.4.0 is a bit buggy in that because it does not keep the saved settings) you can try to print using scale with keep ratio enabled and you should have an output of 15x20 cm aligned with your printer setting wich ever your printer dpi settings are. In your example there won't be any scaling, of course. > > If I print this file with no scaling enabeled, it should be printed out automaticly > at size 15x20cm by using the information 300dpi. That's not true (I'm not a png expert though) because it depends on the printer resolution. But yes here we can fix something, e.g. if not scaling is enabled we could consider the pixel related to the printer resolution, instead of drawing a picture on the page. I'll give a look at it, but if the printer settings is 600dpi don't expect 15x20 cm, but half resolution, and so on with 1200. > Also there should be an option to chose the printout size in percent related to the > original printout-size (which isn't present in the GwenView-version I'm using), I'm not sure we have the same concept of original printout size, I believe something like here: http://www.michaelfurtman.com/pixels.htm > and GwenView should always calculate the printout-size then by using > the additional information of these 300dpi - if present. That info is not present in png, i believe http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html but as i told you i'm not expert in it. We can know the printer resolution setting and use it better as we do scaling pictures. > 100% => 15 x 20 cm > 50% => 7,5 x 10 cm > 150% => 22,5 x 30cm Well you can use scaling with keep ratio enabled for that, and you obtain what you need. When you take a picture from a camera. which is the right printout dimension? Well my camera has 8Mpixels and an output jpeg saved by it is about 3072x3200 pixels, so what is the output in cm? If I take it to a photographer he'll give me a 10x15 cm photo or another standard one so your equation is not valid here. > This is how it's done F O R Y E A R S in MS-Windows programs - > just have a look at XnView or IrfanView or something similar. Don't shout please, I'm trying to understand what you need and moreover what i can do to realize or be near to it. > I simply don't want to be forced to calculate the printout-sizes of images by hand and type > them in manually in the scale-menu of GwenView. Well your gv version is a little buggy there but if you use a scale option with keep ratio enabled and put it to 15x10 for instance into the next release you should find that settings on any other photos, without misshaping it. > But this is how it has to be done in almost all KDE-programs I know of. Well I'm trying to help in printing in gwenview and also in digikam. > Just imagine I do a scan with XSane, save the file somewhere and want to printout it later - > of course the printout should be at the same size as the master. Again not, because of your printer settings. > XSane does store dpi-information in all the common graphic-files (png, tiff, jpg). As far as I know, it doesn't at least into the file. > I don't know why this dpi-information can't be used with most of present Linux-programs (especially KDE), > seem's that noone thought about such a simple need. No it seems we're all sons of the same pice of code ;) Maybe gimp thinks i scan with 300dpi and I print with 300dpi and you think it's working silently. But gwenview is a viewer and nothing else. > The scan-program kooka even isn't able to save the dpi-information of a scanned image - > it's just unbelievable for me => you aren't able to do 1:1 copies with kooka! sorry? Angelo
> Btw. with the MS-Windows-programs like IrfanView or XnView you can also "tweak" the dpi-values of an image (a feature GwenView doesn't provide, also). > This doesn't change not one pixel of the image (the resolution of 1.772 x 2.362 pixel will be kept), but the printout-size of the picture. That is just what i told you, but you can change that it's a print device setting. Just press Print Property. And in such a case i see what you mean and without scaling it doesn't consider that, and that in such a case i could do something. But As I told you i can't find the dpi info anywahere, but in the printer settings.
> * Download the PNG-file I've attached, > * Open a new document in Open Office Writer > * paste the downloaded graphics-file in the OO-document > * look at the size of the image > > And now think about why OpenOffice "knows" its size of exactly 15x20cm! Did you try to reduce the margins before pasting?
Seems that you missed the point and mix up DPI-setting of the printer and DPI-settings stored inside a graphics-file: > That info is not present in png, i believe > http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html > but as i told you i'm not expert in it. We can know the printer > resolution setting and use it better as we do scaling pictures. I can't quote any SPEC's in the moment but as I said before the DPI-info can be stored in almost every common graphic-format like png, tiff or jpg. This DPI-info has nothing to do with the dpi-setup of the printer, but it can be used to determine the printout-size of a picture (as OpenOffice and the GIMP successfully does). Of course both - the DPI-info of the graphic-file AND the DPI-setting of the printer have to be known to get correct printouts. > When you take a picture > from a camera. which is the right printout dimension? > Well my camera has 8Mpixels and an output jpeg saved > by it is about 3072x3200 pixels, so what is the output > in cm? If I take it to a photographer he'll give me a 10x15 cm photo > or another standard one so your equation is not valid here. This is another point - all cameras I know of don't store a DPI-values in the files. => there is no pintout-size defined with these files. But you could do so afterwards - as the JPG-format is able hold dpi-information. >> XSane does store dpi-information in all the common graphic-files (png, tiff, jpg). > > As far as I know, it doesn't at least into the file. Yes, it does - that's what I'm trying to explain you all the time ;-). >> * Download the PNG-file I've attached, >> * Open a new document in Open Office Writer >> * paste the downloaded graphics-file in the OO-document >> * look at the size of the image >> >> And now think about why OpenOffice "knows" its size of exactly 15x20cm! > > Did you try to reduce the margins before pasting? No, I didn't do anything with the margins, but that's the "trick" about DPI-values stored in graphic-files I want to show you - just try it! Right-click on the picture, go into the menu where you can change the dimension of the picture and play around with the scaling of it. Then press the button for "Original size" of the picture and look what happens. I bet the picture will be 15x20cm again - right? I'll prepare some more sample files for you later - you could try-out the behaviour in OpenOffice and compare the files - then you'll see where the dpi-values (it's one for x- and one for y-direction) are stored inside the files. Beside that, with png-format the values are stored in a METRIC format, not in dots per INCH!
Created attachment 19345 [details] TIFF-file with 600dpi
Created attachment 19346 [details] TIFF-file with 1200dpi
Created attachment 19347 [details] JPG-file with 600dpi
Created attachment 19348 [details] JPG-file with 1200dpi
Created attachment 19349 [details] PNG-file with 600dpi
Created attachment 19350 [details] PNG-file with 1200dpi
Now please compare the uploaded files, I've made under MS-Windows with XnView: There was not changed one single pixel - it's still 1.772 x 2.362 pixel. Of course JPG is not a loosless format, so there you will have little deviations. But what you should see now is: All files in the same graphic-format only differ in a view bytes in the header. This is exactly where the DPI-information is stored inside the file! Try out all of them in OpenOffice and look what happens!
This is what Wikipedia says about the PNG-format: http://en.wikipedia.org/wiki/PNG # Metadata chunks # ... # ... # pHYs holds the intended pixel size and/or aspect ratio of the image. I think that is what we need, isn't it? I'm not an expert in graphic formats, but I know that optionaly storing DPI-information in graphic files is possible in most of the graphicformats - you can see that I've done it successfully with all of the uploaded files. With some formats it's not possible - i.e. GIF isn't able to hold that information. IMHO GwenView should take care of the DPI-info (if present) when doing printouts. Moreover it should be possible to tweak the dpi-values with GwenView - as I can already do with IrfanView or XnView under MS-Windows for years.
Well, and here the same for JPG: http://www.obrador.com/essentialjpeg/headerinfo.htm # units -- one byte: Units for the X and Y densities # # * 0 => no units, X and Y specify the pixel aspect ratio # * 1 => X and Y are dots per inch # * 2 => X and Y are dots per cm # Xdensity -- two bytes # Ydensity -- two bytes Please make GwenView using it! Tank you in advance.
You're right, I've learned something new :) The good news is I'm now able to read that data from png files (if present of course) and printing that kind of file correctly. While I can't, by now, read it from jpeg and tiff. Your attachements are useful thanks. I need to talk to Aurelién for that, though.
SVN commit 626335 by anaselli: gwenview now prints a picture without scaling, trying to get its density info if present. (tiff is not supported yet) CCBUG: 129948 CCMAIL: gwenview-general@lists.sourceforge.net M +14 -3 document.cpp M +23 -0 jpegformattype.cpp --- trunk/extragear/graphics/gwenview/gvcore/document.cpp #626334:626335 @@ -411,10 +411,21 @@ size.setHeight( int(hImg * printer->resolution()) ); } else { /* GV_NOSCALE: no scaling */ - size = image.size(); + // try to get the density info so that we can print using original size + // known if it is am image from scanner for instance + const float INCHESPERMETER = (100. / 2.54); + if (image.dotsPerMeterX()) + { + double wImg = double(size.width()) / double(image.dotsPerMeterX()) * INCHESPERMETER; + size.setWidth( int(wImg *printer->resolution()) ); + } + if (image.dotsPerMeterY()) + { + double hImg = double(size.height()) / double(image.dotsPerMeterY()) * INCHESPERMETER; + size.setHeight( int(hImg *printer->resolution()) ); + } } - - + if (size.width() > pdWidth || size.height() > pdHeight) { int resp = KMessageBox::warningYesNoCancel(dialogParentWidget(), i18n("The image will not fit on the page, what do you want to do?"), --- trunk/extragear/graphics/gwenview/gvcore/jpegformattype.cpp #626334:626335 @@ -453,6 +453,29 @@ if(consumer) consumer->end(); + // get the density X and Y info and the related units to have + // the aspect ratio of the image + // field: units -- one byte: Units for the X and Y densities + // 0 => no units, X and Y specify the pixel aspect ratio + // 1 => X and Y are dots per inch + // 2 => X and Y are dots per cm + // Xdensity -- two bytes + // Ydensity -- two bytes + const float INCHESPERMETER = (100. / 2.54); + switch (mDecompress.density_unit) + { + case 0: // no units + break; + case 1: // dots per inch + image.setDotsPerMeterX(int(mDecompress.X_density * INCHESPERMETER)); + image.setDotsPerMeterY(int(mDecompress.Y_density * INCHESPERMETER)); + break; + case 2: // dots per cm + image.setDotsPerMeterX(mDecompress.X_density * 100); + image.setDotsPerMeterY(mDecompress.Y_density * 100); + break; + } + mSourceManager.at_eof = true; (void) jpeg_finish_decompress(&mDecompress);
If I understood correctly you're using Mandriva 2007 (hope i586, if not tell me please) Can you try my patch? You can download patched rpms here: http://www.linux.it/~anaselli/Backport/ You need at least: gwenview-1.4.1-3mdv2007.0.i586.rpm libgwenview1-1.4.1-3mdv2007.0.i586.rpm TIA, Angelo
Sorry, but your packages won't install, seems that there are some mistakes in your dependency definitions.: Installing gwenview-1.4.1-3mdv2007.0.i586.rpm results in: * missing libgwenview1-1.4.0-2mdv2007.0.i586.rpm * dependency gwenview == 1.4.0 not accomplished And installing libgwenview1-1.4.1-3mdv2007.0.i586.rpm: * dependency gwenview == 1.4.1 not accomplished Could you please have a look at it what's going wrong here? > If I understood correctly you're using Mandriva 2007 (hope i586... Yes, correct. > gwenview now prints a picture without scaling, trying to get its density info if present. (tiff is not supported yet) Great!! (although I can't test it, yet...) Now we just would need * support for all graphic-formats which support storing DPI-values * the functionality of defining printout-sizes in percent (related to the "density" which comes with the graphic file - if present) * a function to to "tweak" the the DPI-settings of the graphics-files Seem's if you're going on like this, I can get rid of the GIMP or MS-Windows-programs for my simple picture-tasks, soon... :-)
> Sorry, but your packages won't install, seems that there are some mistakes in your dependency definitions.: Try from root in the directory in which you downloaded them (on the same line): urpmi ./gwenview-1.4.1-3mdv2007.0.i586.rpm ./libgwenview1-1.4.1-3mdv2007.0.i586.rpm > Now we just would need > * support for all graphic-formats which support storing DPI-values That could be a little problematic by now, we could open a new wishlist for that (reminding this one). > * the functionality of defining printout-sizes in percent (related to the "density" which comes with the graphic file - if present) I'm not sure that adds something more than we've got already, since not all the images have that info (or are supported yet), I beleive the scale tab works better (but we can talk about that after). > * a function to to "tweak" the the DPI-settings of the graphics-files Please open a wishlist in kipi-plugins for that, i believe it's the better place for that. > Seem's if you're going on like this, I can get rid of the GIMP or MS-Windows-programs for my simple picture-tasks, soon... :-) eheheh ;)
> Try from root in the directory in which you downloaded them (on the same line): > urpmi ./gwenview-1.4.1-3mdv2007.0.i586.rpm ./libgwenview1-1.4.1-3mdv2007.0.i586.rpm Thank you - this did the trick for me. Yes, seems to work now (tested with one PNG-file. >> * the functionality of defining printout-sizes in percent (related to the >> "density" which comes with the graphic file - if present) > > I'm not sure that adds something more than we've got already, since not all > the images have that info (or are supported yet), I beleive the scale tab > works better (but we can talk about that after). It would of course add something more - because: * you won't have think much about printout-sizes if you want to change the printout-size: half => 50% double => 200% Compared to what you have to do if the original printout-size i.e. is 13,4cm x 17,3cm, what do you have to do? ;-) * the printout size is still dependend to the original size * in case of that DPI-information is not available I would suggest using a standard-value of - let's say 100dpi or so - what do you think? >> * support for all graphic-formats which support storing DPI-values > > That could be a little problematic by now, we could open a new wishlist for > that (reminding this one). Well, I know that one has to read through all the specs of all kind of graphic-formats Gwenview already supports and find out how it works and this is not done from one day to the other. But this is the beginning of it (I hope)...
> I beleive the scale tab works better Btw. - one more suggestion: Leave the scale-tab with all it's functionality with "keep ratio" as it is. Just add a "percent"-tab to the already existing dropdown-menu, where you can already find: * Millimeters * Centimeters * inch + new: percent If "percent" doesn't suit the needs of the format of the values to type in, you could also do a: 1.00 instead of 100% 1.50 instead of 150% 2.00 instead of 200% ... and so on
> Please open a wishlist in kipi-plugins for that, i believe it's the better place for that. Done: http://bugs.kde.org/show_bug.cgi?id=140493 Don't hesitate to vote for it or place comments if you like! ;-)
> Thank you - this did the trick for me. And you have that before any other users ;) > Yes, seems to work now (tested with one PNG-file. and jpeg as well i believe. If so can we close this bug and work on other (new) wishes? > It would of course add something more - because: > * you won't have think much about printout-sizes if you want to change the printout-size: > half => 50% > double => 200% Ok fill a wish for that so that I can take a note for a new implementation on my spare time. > * the printout size is still dependend to the original size If present. > * in case of that DPI-information is not available I would suggest using a standard-value of - let's say 100dpi or so - what do you think? 90 dpi really (the default screen resolution is used), but in most cases, the picture my photocamera's ones for instance, are out of range, so 200% is useless. But I can see what we can do. > Well, I know that one has to read through all the specs of all kind of > graphic-formats Gwenview already supports and find out how it works > and this is not done from one day to the other. > But this is the beginning of it (I hope)... Well some formats are used customized in gwenview, some others not, -we use QT/KDE API- and those are the problem. We can't do anything by now for those formats. Angelo
> Don't hesitate to vote for it or place comments if you like! ;-) Why should I vote what I have to implement to? I should take time instead :p
> Leave the scale-tab with all it's functionality with "keep ratio" as it is. > > Just add a "percent"-tab to the already existing dropdown-menu, where you can already find: > * Millimeters > * Centimeters > * inch > + new: percent I'll se what to do, but the menu should be right that > If "percent" doesn't suit the needs of the format of the values to type in, you could also do a: > 1.00 instead of 100% > 1.50 instead of 150% > 2.00 instead of 200% > ... and so on I'd suggest you to open a new report for that and close this one... Angelo
> and jpeg as well i believe. If so can we close this bug and work on other (new) wishes? > ... > ... > I'd suggest you to open a new report for that and close this one... For what reason you're so anxious about closing this bug and open new ones instead? ;-) For me this doesn't make too much sense, as this bug is still valid in most cases: I guess most of the graphic-formats holding DPI-info are not supported yet and scaling respecting DPI-values isn't implemented, either. >> Don't hesitate to vote for it or place comments if you like! ;-) > > Why should I vote what I have to implement to? I thought this will be done by someone else?!?! For what reason you asked me to fill a new bug-report then, if you're the one to implement this? Do you like to have plenty of it? ;-) Btw: found info's about TIF-format here: http://www.compix.com/fileformattif.htm xresolution and yresolution could be interesting for you... Or do you want an extra bug-report filled for every single graphic-format now? ;-) >> * in case of that DPI-information is not available I would suggest using a >> standard-value of - let's say 100dpi or so - what do you think? > > 90 dpi really (the default screen resolution is used), but in most cases, > the picture my photocamera's ones for instance, are out of range, so 200% > is useless. 90dpi is not really a standard-value for screens: If you have a DDC-comatible monitor the X-server will get its DPI-information via EDID from the monitor. On my computer this is 86x87dpi. But as I said this is value is depending on your monitor. If you don't have a DDC-compatible monitor (which is very uncommon in ourdays) the X-server will fall back to a value of 75dpi. 3rd possibility is to tweak the file /etc/X11/xorg.conf: You could add a line DisplaySize xxx yyy in Section "Monitor" to control the DPI of the X-server. But this is not enough - as I expect you're running Mandriva as well, just have a look at the file /etc/X11/Xresources There you'll find a value called Xft.dpi - it's only for rendering fonts!! I suggested a value of ~100dpi because in my opinion most graphics coming without DPI-info will be screenshots, or images from web-pages. If you optimize the DPI standard-value (let's say to 400dpi) for high-resolution JPG's coming from digital cameras instead, you'll get little spots on paper only when trying to print a screenshot with low resolution with printsize 100%. Maybe many people will think that GwenView didn't print anything at all in this case. If the printsize of highres-JPG's coming without DPI-information is out of range peoble will see that and know what do do. Just compare the behaviour of graphic-files coming without DPI-info in OpenOffice! One other thought about this issue: the equivalent programs to GwenView under MS-Windows (XnView and IrfanView) grey out the option to print the image respecting the DPI-values of the file, if this information is not present. Not bad I would say - perhaps you'll consider this way, also?
Another site with lots of information about graphic-files: http://gpwiki.org/index.php/Category:Fileformat#Graphics:_2D Beside the already mentioned JPG, TIF and PNG you can also find the following formats there which are able to hold DPI-inforamtion as well: * PCX * BMP I bet there a lot more formats out there...
SVN commit 646489 by anaselli: Now jpeg with exif info can be managed for printing without scaling as well. Please Aurélien take a look at it. CCBUG:129948 CCMAIL:gwenview-general@lists.sourceforge.net M +2 -0 gvcore/imageloader.cpp M +60 -0 imageutils/jpegcontent.cpp M +3 -0 imageutils/jpegcontent.h --- trunk/extragear/graphics/gwenview/gvcore/imageloader.cpp #646488:646489 @@ -673,6 +673,8 @@ QSize size = content.size(); d->mProcessedImage = QImage(size, d->mDecoder.image().depth()); } + d->mProcessedImage.setDotsPerMeterX(content.getDotsPerMeterX()); + d->mProcessedImage.setDotsPerMeterY(content.getDotsPerMeterY()); } else { kdWarning() << "ImageLoader::changed(): JPEGContent could not load '" << d->mURL.prettyURL() << "'\n"; } --- trunk/extragear/graphics/gwenview/imageutils/jpegcontent.cpp #646488:646489 @@ -290,6 +290,66 @@ } +int JPEGContent::getDotsPerMeterX() const { + Exiv2::ExifKey keyResUnit("Exif.Image.ResolutionUnit"); + Exiv2::ExifData::iterator it = d->mExifData.findKey(keyResUnit); + if (it == d->mExifData.end()) { + return 0; + } + int XRes = it->toLong(); + Exiv2::ExifKey keyXResolution("Exif.Image.XResolution"); + it = d->mExifData.findKey(keyXResolution); + if (it == d->mExifData.end()) { + return 0; + } + // The unit for measuring XResolution and YResolution. The same unit is used for both XResolution and YResolution. + // If the image resolution in unknown, 2 (inches) is designated. + // Default = 2 + // 2 = inches + // 3 = centimeters + // Other = reserved + const float INCHESPERMETER = (100. / 2.54); + switch (XRes) { + case 3: // dots per cm + return (it->toLong() * 100); + default: // dots per inch + return (it->toLong() * INCHESPERMETER); + } + + return 0; +} + + +int JPEGContent::getDotsPerMeterY() const { + Exiv2::ExifKey keyResUnit("Exif.Image.ResolutionUnit"); + Exiv2::ExifData::iterator it = d->mExifData.findKey(keyResUnit); + if (it == d->mExifData.end()) { + return 0; + } + int YRes = it->toLong(); + Exiv2::ExifKey keyYResolution("Exif.Image.YResolution"); + it = d->mExifData.findKey(keyYResolution); + if (it == d->mExifData.end()) { + return 0; + } + // The unit for measuring XResolution and YResolution. The same unit is used for both XResolution and YResolution. + // If the image resolution in unknown, 2 (inches) is designated. + // Default = 2 + // 2 = inches + // 3 = centimeters + // Other = reserved + const float INCHESPERMETER = (100. / 2.54); + switch (YRes) { + case 3: // dots per cm + return (it->toLong() * 100); + default: // dots per inch + return (it->toLong() * INCHESPERMETER); + } + + return 0; +} + + void JPEGContent::resetOrientation() { Exiv2::ExifKey key("Exif.Image.Orientation"); Exiv2::ExifData::iterator it = d->mExifData.findKey(key); --- trunk/extragear/graphics/gwenview/imageutils/jpegcontent.h #646488:646489 @@ -43,6 +43,9 @@ Orientation orientation() const; void resetOrientation(); + + int getDotsPerMeterX() const; + int getDotsPerMeterY() const; QSize size() const;
Hello there! Just wanted to ask if you could please add the same printing functionality for the following graphic-formats (which can hold DPI-Information as well): * BMP * PCX * TIF I'll attach some more sample image-files for you. Next question is about implementing my suggestion (see comment #28) to enhance GwenView's printing-functionality, so GwenView would be able to scale the print-out in percent-values (respecting DPI-informations of a graphic-file, if present). Would be nice if I could see some progress here, soon.
Created attachment 21970 [details] BMP-file with 300dpi
Created attachment 21971 [details] BMP-file with 600dpi
Created attachment 21972 [details] PCX-file with 300dpi
Created attachment 21973 [details] PCX-file with 600dpi
In comment #30 Angelo Naselli writes: > Well some formats are used customized in gwenview, some others not, > -we use QT/KDE API- and those are the problem. We can't do anything by > now for those formats. Found this on Trolltechs website: http://doc.trolltech.com/3.3/qimage.html#dotsPerMeterX QImage::dotsPerMeterX/Y should pretty much do what is needed, doesn't it? For those image-formats being able to hold DPI-information GwenView still doesn't respect given size of an image when being printed: * BMP * PCX * TIF
> In comment #30 Angelo Naselli writes: > > Well some formats are used customized in gwenview, some others not, > > -we use QT/KDE API- and those are the problem. We can't do anything by > > now for those formats. > > Found this on Trolltechs website: http://doc.trolltech.com/3.3/qimage.html#dotsPerMeterX > QImage::dotsPerMeterX/Y should pretty much do what is needed, doesn't it? Are you kidding me? No seriously, please if you know i made a mistake add a patch, but don't say that... Just read the code and see what doPaint does... As I said it seems not all the image formats are loaded correctly by qt interface. I added the jpeg management using Aurelien interface, because it was missed for instance...
> Are you kidding me? Why are you talking to me this way? I don't think it's necessary to be rude. I came along on to Trolltech's Doc's with another bug concerning GwenView by accident, and read about dotsPerMeterX/Y then. Neither I have any experiences in programming to add patches, nor I don't know what presently can't be done by Qt-interface regarding image-handling. Please don't get me wrong only if this "dotsPerMeterX/Y" doesn't help you.
> > Are you kidding me? > Why are you talking to me this way? I don't think it's necessary to be rude. Well apologize if hurt your feeling, I'm not used to. Anyway I always took in account user suggestions, yours in this room more than ever, but your last, sounded like a joke to me since you suggested to use what is *already* in...
Did you have a look how things are done in Konqueror? If you rightclick on the "Properties"-Dialog on "Meta-Info", you can see the DPI-values on many image-formats, while on some they are not visible. DPI-values of TIF and PCX can be seen this way. Maybe you'll find some inspiration how things could be done in the sources of Konqueror?!?!
Created attachment 23136 [details] Meta-Info in Konqueror
> Would be nice if I could see some progress here, soon. Get lost.
Hum... sorry, lost my temper. Shouldn't have written that. Still, please keep in mind how much you paid before expecting bugs to be fixed "soon". If it doesn't suit you, we can offer you a refund. Your bug is valid, although it is unlikely it's going to be fixed in 1.4. It would be nice to check if Qt 4 still does not report correct dpi info for all image formats.
> Your bug is valid, although it is unlikely it's going to be fixed in 1.4. It would be nice to check > if Qt 4 still does not report correct dpi info for all image formats. > Just a note though Aurelien, I'm not familiar with all the gv code of course, but Comment #45 is a good point. Why retreaving extra info, even from gwenview, gives dpi info for such image formats? Somewhere it is managed indeed.... Cheers, Angelo
Information shown in property dialogs are produced by KFile plugins. KFile plugins working on images may or may not use QImage loaders to get their information. The right thing to do IMO is to make sure QImage loaders are able to get the same information as KFile plugins.
> Get lost. > ... > ... > please keep in mind how much you paid before expecting bugs to be fixed "soon". > If it doesn't suit you, we can offer you a refund. ??? What's all this fuss about? I've opened this bug in year 2006 (June) because I believe that the present version of GwenView already is a good image-viewer for KDE, and I wanted to help you to even make it better. I know that implementing all this is not done from one day to the other. Almost 1,5 years!!! later (2007, November) I asked to have a look on this bug again (as it could have been out of sight, which simply is the reason sometimes for open bugs I am/was involved in), saying it would be nice if there would be some progress on it. In my opinion there is a SLIGHT difference between "expecting" bugs to be fixed or "it would be nice if" it would be done. Therefore your present reaction is somewhat strange to me. Mabe you've also noticed that English is not my native language, so if you got me wrong because of my jolty wording I apologize for that. I don't "expect" anything from you. I don't know if you work on GwenView in your spare-time or not, I just assume it is all your spare-time. If you would argue in a way like; you neither have time nor will to do it in the moment (as done in bug #156150), or even don't reply at all, I absolutely respect that. I just would be a great pity in my point of view, if you don't take this bug in account no more, because you feel that I'll get anoying in your eyes, because there recently are some more open bugs or wishes concerning GwenView I'm involved in. This absolutely is NOT my intention! Cheers!
Saying this "Would be nice if I could see some progress here" sounds like you believe we owe you something. The "soon" at the end of the sentence makes it sound like you are getting upset not seeing this progress we are supposed to owe you. That's my interpretation of your sentence, I am not a native english speaker, so I may be wrong or you may not have wanted to express this.
Hey, maybe this could be useful: http://developer.kde.org/documentation/tutorials/kfile-plugin/x503.html Especially section "Handling meta-data yourself" => "Extracting a specific data element"
I've read the code and found it reads data from raw, I'll talk to Aurelien as soon as possible.
> KFile plugins working on images may or may not use QImage loaders to get their information. It seems not to. > The right thing to do IMO is to make sure QImage loaders are able to get the same information as KFile plugins. Yes but i don't know how to put the code, i mean next code: if (d->mImageFormat == "PCX") { Q_UINT16 HDpi; char * pt=(char*)&HDpi; pt[0] = d->mRawData[12]; pt[1] = d->mRawData[13]; Q_UINT16 YDpi; pt=(char*)&YDpi; pt[0] = d->mRawData[14]; pt[1] = d->mRawData[15]; const float INCHESPERMETER = (100. / 2.54); kdDebug() << "ImageLoader::finish(): " << HDpi << "x" << YDpi << " dpi" << endl; d->mProcessedImage.setDotsPerMeterX(float(HDpi *INCHESPERMETER)); d->mProcessedImage.setDotsPerMeterY(float(YDpi *INCHESPERMETER)); } Inside ImageLoader::finish() do the trick but it doesn't work because the image is not updated inside doPaint. Angelo
Angelo Naselli a écrit : [bugs.kde.org quoted mail] Do you mean you see the correct info in the debug output but it doesn't get propagated to ::doPaint? BTW: This code: > char * pt=(char*)&HDpi; > pt[0] = d->mRawData[12]; > pt[1] = d->mRawData[13]; Will probably break on a big endian machine. It should be rewritten like this: Q_UINT16 low = (Q_UINT16)d->mRawData[12]; Q_UINT16 high = (Q_UINT16)d->mRawData[13]; HDpi = (high << 8) + low;
> Do you mean you see the correct info in the debug output but it doesn't > get propagated to ::doPaint? It seems so, and it if you look at the output of kdDebug() << "ImageLoader::finish(): " << HDpi << "x" << YDpi << " dpi" << endl; you can see that dpi info is correct also for png and maybe for other image formats... but inside the doPaint they are not in. IIRC png files are managed by our code, and inside dpi info is managed. I suspect my changes for exif dpi info is not working :/ > Q_UINT16 low = (Q_UINT16)d->mRawData[12]; > Q_UINT16 high = (Q_UINT16)d->mRawData[13]; > HDpi = (high << 8) + low; > Yes you're right that was... just a try nothing to be released :) Angelo
Angelo Naselli a écrit : [bugs.kde.org quoted mail] Is it happening on a one 1bpp PCX file? Maybe it's related to the fact that we change depth? In this case, try another file.
This bug is over 3 years old. I can not reproduce this bug, is it still an issue in KDE 4.7.4/Gwenview 2.7.4?
Setting status correctly.
Closing based on comment #59
Hi there, although this bug is very old, it seems that it's not fixed completely. For testing, "fit in page"-option was disabled. * BMP-file: o.k. * TIF-file: o.k. * PNG-file: o.k. * PCX-file: impossible to open * JPG-file: printer does output a completely white paper! Printing JPG-file does work only, if "fit-in-page"-option was choosen. It then does not have exact printout-size, anymore. Tested with KDE/Gwenview 4.10.1 on Fedora FC18