<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Add support for printing to a Windows printer from pdftocairo" href="https://bugs.freedesktop.org/show_bug.cgi?id=79936#c2">Comment # 2</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Add support for printing to a Windows printer from pdftocairo" href="https://bugs.freedesktop.org/show_bug.cgi?id=79936">bug 79936</a> from <a class="email" href="mailto:ajohnson@redneon.com" title="Adrian Johnson <ajohnson@redneon.com>"> Adrian Johnson</a> <pre>Thanks for implementing the suggested print options. This should make it easier to later add new print options. > * The '-printopt duplex' option somewhat overlaps with the '-dupex' > option, but I'm not sure if it is wise to mix them ('-dupex' is a > boolean, but -'-printopt duplex' has three values). > * There are many more '-printopt' to be added, and some overlap with > older options, such as '-duplex' and '-paper' and maybe others. I > don't know exactly what should be done with them. You only need to add what you need. Other options can be added later. Where there is overlap with existing options, the existing options should be used to set the printing options. Users expect these options to work across all output formats. If an existing option does not support all the functionality we can make the -printopt version override the old one (maybe with a warning about duplicated options). > * If we add more '-printopt', then it may be prudent to split the > parsing functions into a separated file. That may complicate the > Makefile, but make the code easier to work with. I have no > preference about it... I would like the win32 code to be in a separate file (eg pdftocairowin32.cc). This keeps windows.h (which tends to pollute the namespace) out of pdftocairo.cc and makes the code easier to read. For example the changes to the beginDocument() function can be reduced to: if (print) { #ifdef CAIRO_HAS_WIN32_SURFACE win32BeginDocument(printer); #endif } else if (printing) { .... } The #ifdefs should test for CAIRO_HAS_WIN32_SURFACE instead of _WIN32 since building on windows does not mean that cairo has the win32 backend compiled in. I'm not sure how easy it is to make the build system compile pdftocairowin32.cc only when CAIRO_HAS_WIN32_SURFACE is defined. Probably the easiest thing is to just wrap pdftocairowin32.cc in a #ifdef CAIRO_HAS_WIN32_SURFACE. This is what we do in the cairo source. I recommend using git diff or at least turn on the -p option of diff so I can see what function each change is in. I don't like the use of an integer in the source option. Why would we need to support a number that is not one the #defines for DEVMODE? It would be nicer if parseSource used a table instead of multiple if statements for matching the source. eg see standardMedia in PSOutputDev.cc. When setting printer options in devmode you are setting the corresponding flag in dmFields. My interpretation of the DEVMODE documentation is that the devmode structure for a printer only supports setting the options indicated in the dmFields member. ie you should not be changing dmFields but instead check to see if an option is supported in dmFields before setting the option. The paper size in devmode should be set to the values in paperWidth and paperHeight. Looking at devmode we should be able to just convert the width/height to units of 0.1mm and put it in dmPaperWidth/dmPaperHeight. The paper size is also used to scale and translate the pdf page depending on the -expand/-noshrink/nocenter options. For this to work correctly the paper width and height returned by getOutputSize() should match the device context. ie the values obtain from GetDeviceCaps should be used. Note that the windows printing device context positions the origin at the top left of the printable area. This works well for the default pdftocairo settings where large pages are shrunk to fit the paper size. If -noshrink is used it would be better to use the full width and height of the paper. ie printing an A4 pdf to A4 paper with -noshrink should not scale the document even if it means any content outside the printable area will be lost. I would recommend doing the scaling from physical size to points on the hdc. This avoid the need make win32 specific changes to the cairo matrix transformation code. I suggest something like this after creating the hdc: XFORM xform; double xOffset, yOffset; double xPointsToDev = GetDeviceCaps (hdc, LOGPIXELSX)/72.0; double yPointsToDev = GetDeviceCaps (hdc, LOGPIXELSY)/72.0; if (noShrink) { outputPaperWidth = GetDeviceCaps (hdc, PHYSICALWIDTH)/xPointsToDev; outputPaperHeight = GetDeviceCaps (hdc, PHYSICALHEIGHT)/yPointsToDev; xOffset = GetDeviceCaps (hdc, PHYSICALOFFSETX); yOffset = GetDeviceCaps (hdc, PHYSICALOFFSETY); } else { paperWidth = GetDeviceCaps (hdc, HORZRES)/xPointsToDev; paperHeight = GetDeviceCaps (hdc, VERTZRES)/yPointsToDev; xOffset = 0; yOffset = 0; } SetGraphicsMode (hdc, GM_ADVANCED); xform.eM11 = xPointsToDev; xform.eM12 = 0; xform.eM21 = 0; xform.eM22 = yPointsToDev; xform.eDx = xOffset; xform.eDy = yOffset; SetWorldTransform (hdc, &xform); and use the outputPaperWidth/Height in getOutputSize(). EndDoc and DeleteDC should be called after cairo_surface_finish and cairo_surface_destroy. The pdftocairo.1 man page needs to be updated to include the new options. I suggest including -print, -printer, and -printopt in the OPTIONS section noting that they are windows only. Put the details of the -printopt supported options in a new section named WINDOWS PRINT OPTIONS. In DOCINFO put the actual pdf filename if available. If reading from standard input I suggest using the document name "pdftocairo <stdin>". Win32 calls that have both ansi and unicode versions should have an "A" or "W" to specify which one we are using. eg DeviceCapabilitiesA. The "Error: one of the output format ..." error message should only include "-print" if this option has been compiled in.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>