[Bug 822102] New: off-center printing on Minolta Magicolor 3300
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c0 Summary: off-center printing on Minolta Magicolor 3300 Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Printing AssignedTo: jsmeix@suse.com ReportedBy: Joseph.Comfort@asu.edu QAContact: jsmeix@suse.com Found By: --- Blocker: --- Created an attachment (id=541631) --> (http://bugzilla.novell.com/attachment.cgi?id=541631) Sample .pdf graph User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:20.0) Gecko/20100101 Firefox/20.0 I have used a Minolta Magicolor 3300 printer on OpenSUSE for several years. The Magicolor 3100 driver comes with the system, and that has worked well. The printing is done over a network TCP connection (from several computers). With v12.3, some graphics documents are printing off-center; the axis labels are shifted into the margin regions or beyond. I have not found problems with ascii text, web pages, or PDF documents (e.g., from LaTeX). The graphs are made by some old (and well used) programs that generate .eps files, which are then converted to .pdf. In these cases, _both_ the .eps and .pdf prints are off-center. The off-center printing happens with the commandline 'lpr -P<...>' command. The graphs print centered from acroread, okular, and xpdf (for which I must use the lpr command). They also print correctly from computers with the v12.1 system, or on a Brother printer at home. A graph, produced on a computer with the v12.3 system, is attached. Reproducible: Always Steps to Reproduce: 1. Setup CUPS printing on a Magicolor 3300 printer on OpenSUSE 12.3. 2. Use the lpr command to print the attached graph. 3. Actual Results: Printing is off-center Expected Results: Centered -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c1 Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Platform|x86-64 |All Found By|--- |Community User Resolution| |INVALID --- Comment #1 from Johannes Meixner <jsmeix@suse.com> 2013-06-04 06:50:06 CEST --- I do not have a Minolta Magicolor 3300 printer. Therefore I cannot reproduce your particular issue. What I did on my openSUSE 12.3 system to try to reproduce it as far as possible was: 1.) I added a "FileDevice yes" line to /etc/cups/cupsd.conf and restarted the cupsd. 2.) I set up a print queue for a Minolta Magicolor 3100 printer that outputs into a file using the command: # lpadmin -p testy \ -v file:///tmp/testy.prn \ -m OpenPrintingPPDs/postscript/Minolta-magicolor_3100.Postscript.ppd.gz \ -E 3.) I printed your attachment #541631 via this print queue into the file /tmp/testy.prn using the command: $ lp -d testy bug-822102_cv_range.pdf 4.) Because the Minolta Magicolor 3100 is a PostScript printer, the printout in /tmp/testy.prn is a PostScript file so that one can view it using Ghostscript via the command: $ gs -r75 /tmp/testy.prn 5.) To compare the printout in /tmp/testy.prn with the original PDF I viewed also your attachment #541631 using the Adobe Reader (i.e. via the "acroread" command). I don't see a visual difference between the printout as shown by Ghostscript compared to the original PDF as shown by "acroread". Therefore - from my point of view - the printout is correct. I cannot reproduce how the printout gets printed off-center on your particular Minolta Magicolor 3300 printer. Perhaps it helps when you print it using the "fitplot" or "fit-to-page" printing option in CUPS as described in http://en.opensuse.org/SDB:Landscape_Printing For printing it is crucial that the content of the original PDF page fits in the printable area of the paper of your particular printer. When printing an arbitrary PDF page with plain "lpr" there is no automated functionality that fits the content on the paper. The command $ gs -sDEVICE=bbox -dBATCH -dNOPAUSE bug-822102_cv_range.pdf \ | grep '%BoundingBox' results "%%BoundingBox: 0 0 632 519". This shows that the content of your original PDF page does not fit on usual A4 paper because A4 paper has those dimesions (see your PPD file) PaperDimension A4/A4: "595 842" The Minolta-magicolor_3100.Postscript.ppd.gz file shows those printable area for A4 paper: ImageableArea A4/A4: "14.17 14.17 580.83 827.83" Because the content of your original PDF page does not fit in the printable area of the paper of your particular printer, it cannot print correctly using plain "lpr". Therefore the issue is no bug and I close it as "invalid". I don't know why it worked for you with older openSUSE versions. When it worked with older openSUSE versions it was only by luck. See http://en.opensuse.org/SDB:Landscape_Printing for some more information. Background information: The reason that you can print via the Adobe Reader is: When you print a PDF from the Adobe Reader, the Adobe Reader itself converts the PDF to PostScript so that the Adobe Reader sends PostScript to CUPS. The Adobe Reader provides "Autorotate Scale and Center" features to make the the content of the original PDF page fit on paper and that is the reason why the printout is centered when printing from the Adobe Reader. In contrast when you print a PDF not via the Adobe Reader, CUPS runs first of all /usr/lib/cups/filter/pdftops which is a wrapper that calls /usr/bin/pdftops that actually converts PDF to PostScript (/usr/bin/pdftops belongs to the poppler-tools RPM). Perhaps there is no automated "Autorotate Scale and Center" feature in /usr/bin/pdftops and then it does not print centered. When CUPS gets PDF it must convert it into PostScript because CUPS needs PostScript so that CUPS can add the PostScript snippets from the PPD file to enable this or that printer-specific option, see https://en.opensuse.org/Concepts_printing and https://en.opensuse.org/SDB:CUPS_in_a_Nutshell#PPD_Files Furthermore there is /usr/bin/pdf2ps (/usr/bin/pdf2ps belongs to the ghostscript RPM) that also converts PDF to PostScript which is a bash script that calls Ghostscript to actually do the conversion. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c2 --- Comment #2 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-04 12:28:45 UTC --- Johannes, Thank you for your thoughtful analysis and informative comments. I am sure I found a bug, but it is either (a) disappearing with system/rpm updates and/or (b) it is elsewhere. (Due to additional work, the figure got regenerated, so it might be affected by system updates.) Some observations. 1) The print media was letter (612x792), not A4, so the size was OK (with the landscape figure rotated to portrait). 2) My earlier comment that both the .eps and the .pdf files printed off-center seems no longer to be correct. The .eps now prints centered, but the .pdf does not. 3) More significantly, the BoundingBox in the .eps file was 44 74 562 706. However, in the conversion to .pdf, it got changed to 0 0 518 632 (subtracting off the lower corner). Hence, it printed off-center -- at least on v12.3. (It is still a mystery why it works on v12.1.) I think I have now identified the culprit. If I use ps2pdf to convert, the BB in the .pdf file becomes 0 0 612 792. However, if I use the 'convert' command (from ImageMagick), it is 0 0 518 632. The first one prints centered; the second does not. How should this issue be reported? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c3 Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P4 - Low Status|RESOLVED |REOPENED Resolution|INVALID | Summary|off-center printing on |ImageMagick: |Minolta Magicolor 3300 |/usr/bin/convert .eps file | |into PDF changes bounding | |box which results | |off-center printing --- Comment #3 from Johannes Meixner <jsmeix@suse.com> 2013-06-05 03:52:32 CEST --- I need to reproduce what you found out in comment#2. Therefore please attach your .eps file to this bug and provide your exact commands both for 'ps2pdf' and for 'convert' that you used to convert your .eps file into PDF. Off the top of my head I think it is basically undefined how conversion into PDF should happen by default regarding the bounding box as long as the resulting bounding box is still "technically correct" (i.e. as long as the bounding box encloses all marks painted on the page) - what I mean is: Assume in a PostScript file the bounding box is 10 20 300 400 then after conversion into PDF the bounding box could be still 10 20 300 400 or it could be changed to 0 0 290 380 as long as the painted marks are moved accordingly so that they are still inside the bounding box. In particular the 'convert' program has many options to specify (almost) anything so that you may have to explicitly set an option that tells 'convert' the right position, see in particular the "-page" option in "man convert". For details about 'convert', point your browser to /usr/share/doc/packages/ImageMagick/www/convert.html and for details about the "-page" option, point your browser to /usr/share/doc/packages/ImageMagick/www/command-line-options.html#page
From my experience with 'convert', I always needed some trial and error until I found the right set of options so that 'convert' results what I needed in each particular case.
-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |Joseph.Comfort@asu.edu -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c4 Joseph Comfort <Joseph.Comfort@asu.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |REOPENED InfoProvider|Joseph.Comfort@asu.edu | --- Comment #4 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-05 22:50:40 UTC --- Created an attachment (id=542882) --> (http://bugzilla.novell.com/attachment.cgi?id=542882) Set of test files -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c5 --- Comment #5 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-05 22:58:52 UTC --- I wrote an extended description of what the files are in the attachment. I committed the comment and submitted the attachment. The was some message about a mid-air collision. I do not see my comment. If it does not show up and can not be located, please let me know and I will regenerate it. Thank you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c6 --- Comment #6 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-05 23:51:06 UTC --- I wrote an extended description of what the files are in the attachment. I committed the comment and submitted the attachment. The was some message about a mid-air collision. I do not see my comment. If it does not show up and can not be located, please let me know and I will regenerate it. Thank you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c7 --- Comment #7 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-06 00:37:44 UTC --- I will redo the comment. I extended the study, and the issue is getting murkier. The attached file contains 12 files: 6 files cv_range... from work (with the Minolta printer), and 6 files xcv_range... from home (with a Brother HL-5340D printer). The 4 .eps files are all duplicates. The pdf files of each set are distinguished as follows: cv_range.pdf Convert: ps2pdf cv_range.eps cv_range.pdf cv_range2.pdf Convert: convert cv_range.eps cv_range2.pdf cv_range3.pdf Convert: convert cv_range.eps -page 612x792 cv_range3.pdf cv_range4.pdf Convert: epstopdf cv_range4.eps The xcv_... files were generated at home the same way. The two computers are both x86_64 and are set up with identical rpms. At work -- cv_range.pdf prints centered correctly (identical to cv_range.eps) cv_range2.pdf prints off-center, but with the correct image size cv_range3.pdf prints off-center, but with the correct image size cv_range4.pdf prints centered correctly, with the proper image size At home -- xcv_range.pdf prints centered correctly (identical to xcv_range.eps) xcv_range2.pdf prints centered, with the image size expanded to fill the page xcv_range3.pdf prints off-center, but with the correct image size xcv_range4.pdf prints centered, with the image size expanded to fill the page The xcv*.pdf file sizes are the same as the cv*.pdf sizes. The xcv files also display exactly the same way as the corresponding cv files on acroread, okular, and xpdf. These displays are the same as described for the home computer (not the work computer). Looking inside the files, the corresponding pairs appeared to be the same, but the 'cmp' command shows differences. Thus: (a) the different methods for converting a .eps graph image to a .pdf image give different results on computers with identical setups; (b) the .pdf files print differently on the computers; (c) the image size is properly kept on one computer, but not the other; there is off-center printing that did not occur in earlier openSuSE versions. I appreciate your advice about the 'convert' command, and the confusion that can come from the large number of options. I started using it at one time because it was a quick and easy way to convert to different formats at the same time, without having to remember the names of particular commands. It had worked, but I will try to avoid it. It would be very nice if the different conversion methods could give the same results all the way through the display and printing stages in different computers. I don't know whether it is better to have automatic scaling or not, but at the moment any control for it seems to be hidden. Automatic centering is perhaps the best option, but then it should happen (as in the past). Things have become very confusing. I appreciate your attention and help. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c8 --- Comment #8 from Johannes Meixner <jsmeix@suse.com> 2013-06-07 06:54:24 CEST --- I don't know what your "epstopdf" is. Could you call this command with all the parenthesis ( set -x ; rpm -qf $( type -P epstopdf ) ) and post its output so that I know which RPM provides epstopdf. Regarding convert: As I wrote in comment#3 one needs trial and error until 'convert' results what one needs. In your case using your files from your attachment#542882 this works for me: convert cv_range.eps -page 612x792+35+75 cv_range.convert-page.pdf Now my cv_range.convert-page.pdf looks same when I view it with Ghostscrit as the original cv_range.eps -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c9 Johannes Meixner <jsmeix@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Component|Printing |Other Resolution| |INVALID QAContact|jsmeix@suse.com |qa-bugs@suse.de --- Comment #9 from Johannes Meixner <jsmeix@suse.com> 2013-06-07 09:02:45 CEST --- If you like to get some feedback from 'convert' what it does, use the -verbose option, e.g. for me: -------------------------------------------------------------------------------- $ convert -verbose cv_range.eps -page letter+35+75 cv_range.convert-page.pdf "gs" -q -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 "-sDEVICE=pngalpha" -dTextAlphaBits=4 -dGraphicsAlphaBits=4 "-r72x72" -g518x632 "-sOutputFile=/tmp/magick--RZb0vzu-%08d" "-f/tmp/magick-wwWGDsWA" "-f/tmp/magick-RPjrMGoH" /tmp/magick--RZb0vzu-00000001 PNG 518x632 518x632+0+0 8-bit DirectClass 22.6KB 0.030u 0:00.020 cv_range.eps PS 518x632 518x632+0+0 16-bit DirectClass 22.6KB 0.000u 0:00.000 cv_range.eps=>cv_range.convert-page.pdf PS 518x632 612x792+35+75 16-bit DirectClass 94.2KB 0.050u 0:00.059 -------------------------------------------------------------------------------- This shows (you could also use "strace -f" to get the "gs" call) that 'convert' calls internally Ghostscript to convert the EPS into a bitmap image (via the Ghostscript device pngalpha). Afterwards 'convert' encapsulates the bitmap image into a PDF. I agree that from an end-user point of view "It would be very nice if the different conversion methods could give the same results all the way through the display and printing stages in different computers" but the present situation is that there is neither such a thing as a general guideline or specification nor is there a general agreement which same result all those different conversion methods should give. As matters stand the different conversion tools are made by different open source software projects with different use-cases in mind where each has its own reasoning behind what each particular default behaviour is. I am not involved in the ImageMagick open source software project so that I cannot decide about the 'convert' default behaviour. According to http://www.imagemagick.org "ImageMagick is a software suite to create, edit, compose, or convert bitmap images." That means the primary focus are bitmaps (and not vector graphics like PostScript usually has) and I assume that for bitmaps the 'convert' default behaviour is best. In contrast the main focus of Ghostscript is PostScript and PDF in particular regarding printing output so that the 'ps2pdf' default behaviour fits better for printing output. Bottom line from my point of view: Regardless that 'convert' works to convert PS/EPS into PDF it is not the best tool for it because it is meant to work with bitmap images. In contrast 'ps2pdf' is primarily meant to convert PS/EPS into PDF. I close the issue again as "invalid" because there is no actual bug. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c10 --- Comment #10 from Johannes Meixner <jsmeix@suse.com> 2013-06-07 09:07:56 CEST --- Regarding different results on computers with identical setups when using 'convert' and 'epstopdf': If you like to get those issues analyzed, please file one separated bug for ImageMagick/convert and only if your 'epstopdf' is from an official openSUSE 12.3 RPM, please file another separated bug for 'epstopdf'. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=822102 https://bugzilla.novell.com/show_bug.cgi?id=822102#c11 --- Comment #11 from Joseph Comfort <Joseph.Comfort@asu.edu> 2013-06-07 13:44:46 UTC --- epstopdf is a perl script found in: texlive-epstopdf-bin . Documentation is in texlive-epstopdf . As you say, considering the sources, getting consistency among the various conversion methods can be difficult. My complaint is that something changed between openSuSE v12.1 and v12.3 so that conversion and printing which worked for a long time now fails. So I question the notation 'invalid.' To the user, something has gone wrong, and some previous consistency is lost. I did the same tests on a v12.1 system at work, printing to the same Minolta printer as before. I get SuSE v12.1 -- cv_range.pdf prints centered, but not identical to cv_range.eps; actually a bit larger and centered better than the .eps file or v12.3. cv_range2.pdf identical with cv_range.pdf (previous line) cv_range3.pdf prints off-center, with the same size as cv_range2.pdf cv_range4.pdf centered and identical with cv)range.pdf and cv_range2.pdf The '-page 612x792' (alone) option is not good anywhere. Here, ps2pdf, convert (alone), and epstopdf all give the same nice result. The v12.3 behavior is different, and wrong in some aspects. The root cause seems to be something outside of convert or epstopdf, so I will hold off on bug reports about them. The epstopdf files are identical on the two SuSE versions. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com