<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#c5">Comment # 5</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:rodrigorivascosta@gmail.com" title="rodrigo <rodrigorivascosta@gmail.com>"> rodrigo</a> <pre>(In reply to <a href="show_bug.cgi?id=79936#c2">comment #2</a>) > 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). Done! > I would like the win32 code to be in a separate file... Done! > The #ifdefs should test for CAIRO_HAS_WIN32_SURFACE instead of _WIN32... Done! > I'm not sure how easy it is to make the build system compile > pdftocairowin32.cc only when CAIRO_HAS_WIN32_SURFACE is > defined... I simply added `#include "pdftocairowin32.cc"` to the main source. Some people will frown upon it, but I think it fits nicely the one-source-file-but-not-quite character of pdftocairo. Moreover, this way we avoid the need to extern-declare all the globals and functions. > I recommend using git diff... Done! > It would be nicer if parseSource used a table... Done! > The paper size in devmode should be set to the values in paperWidth > and paperHeight... Done, I think. > 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. Sorry, I get lost with all these options and transformations. I tried to do what you suggested but I couldn't get it right. Sometimes the text is fine but the images go crazy, sometimes is the other way around. The only way that I got it to work for every PDF I tested is the one in the original patch: modifying the cairo matrix. I suspect that cairo may be playing with the HDC transformation too, but I didn't check it... > 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: > > [code snip] > > and use the outputPaperWidth/Height in getOutputSize(). I tried that, too, but it didn't work. One problem is that `getOutputSize()` is called *before* CreateDC(), but all these computations require the HDC. So you have a kind of chicken-egg situation... > EndDoc and DeleteDC should be called after cairo_surface_finish and > cairo_surface_destroy. I tried moving it, but I fails badly. The problem is that after `cairo_surface_finish()` calling `cairo_win32_surface_get_dc()` will return NULL. I don't know if the HDC is really destroyed, or if it would leak. With a display HDC it would be bad enough, but with a printer HDC it is terrible, as the printer job may never finish. > The pdftocairo.1 man page needs to be updated... Done! I'm notably bad at writing man pages, so feel free to improve. > In DOCINFO put the actual pdf filename if available. If reading from > standard input I suggest using the document name "pdftocairo <stdin>". Done! > Win32 calls that have both ansi and unicode versions should have an > "A" or "W" to specify which one we are using. eg DeviceCapabilitiesA. I don't see the point, but it is easy, so, done! I also added a check to the return value of `StartDocA()` because it will return an error with the XPS driver if the user presses "Cancel" in the "Save File" dialog. > The "Error: one of the output format ..." error message should only > include "-print" if this option has been compiled in. That would be easy enough, but I feel it a bit unfair. -ps, -eps, -pdf and -svg options can also be disabled at compile time but they are unconditionally listed. (Just half-kidding). -- That all said, there is still room for improvement. For example, I found that there is that function ResetDC(), that can be used just before `StartPage()` to change the DEVMODE for each page. That is way beyond my original intents, but it is nice to know.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>