[Poppler-bugs] [Bug 79936] Add support for printing to a Windows printer from pdftocairo

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=79936

--- Comment #2 from Adrian Johnson <ajohnson at redneon.com> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler-bugs/attachments/20140729/f40968e7/attachment.html>