<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#c18">Comment # 18</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#c8">comment #8</a>) > I finally found some time to look at this bug again. I will attach some > patches that fix a number of issues. Have a look and check that I have not > broken anything. Great news! > The major fix is the for the page size issue. I have fixed it to make all > the various options (-paper, -origpapersizes, -noshrink, -nocenter) work. I > had the same issue you mentioned with images not appearing. I have fixed it > in cairo. The patch is: > > <a href="http://cgit.freedesktop.org/cairo/commit/">http://cgit.freedesktop.org/cairo/commit/</a> > ?id=0aa43ed886c0f8468a21a470f2f024bd4d8a4513 That proves that the Windows' backends need more love... BTW, I'm preparing a easier and more modular rewrite of my MinGW cross-compilation suite. I'll add it to github once it is ready for showing. > The only remaining issue I have is with the numeric value for the source > option. If we are going to support non standard sources we should use > DeviceCapabilities() with DC_BINNAMES to obtain the names and allow the user > to enter the text name of the source. Otherwise I suggest removing the > numeric value capability. As you wish. I don't have a real need for that. Maybe in the real world these custom BIN values are seldom used, I don't know. If you don't like the numbers, probably it is not worth doing anything until someone really needs it. > I also noticed in the documentation for DocumentProperties() at > <a href="http://msdn.microsoft.com/en-us/library/windows/desktop/dd183576%28v=vs">http://msdn.microsoft.com/en-us/library/windows/desktop/dd183576%28v=vs</a>. > 85%29.aspx > that we are not doing step 5 in the "To make changes to print settings that > are local to an application, an application should follow these steps:" > section. It seems to work without the extra call to DocumentProperties() but > I am wondering if we should do exactly what the documentation says to do to > change the print settings. Interesting... I really don't what is this last call for. Maybe it is for user selection validation, or something like that. But that could easily been done at `CreateDC()`... But now that we are into it, would it make sense to add a CLI option to show the printer property sheet? That is, to call `DocumentProperties()` with the `DM_IN_PROMPT` flag. I think that it could be done easily. Add the call from step 5 of the reference doc, but just add the `DM_IN_PROMPT` flag iff the `-prnproperties` (or whatever) option is used.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>