Hi there. I have a big problem. With the last XOJO version, when I compile an application for Windows that have an output on the printer, it ever prints at very low resolution, not respecting borders too.
Have I lost something on the change log?
Many thanks…
Yeah, printing in 2016r4 is not happy with life.
http://bkeeneybriefs.com/2016/12/windows-printing-broken-in-xojo-r4/
Please use older Xojo version if you need printing on Windows.
Ok thanks… But this is not a good way to work… If I made a big mistake on one of my application, I fix it working all night if it’s necessary, but Xojo take it (too much) easy. They’d have to fix it yesterday!!! 
This is high quality printing. For your convenience in a special brick mode.
It is much easier to count the points now!
[quote=311442:@Christian Schmitz]This is high quality printing. For your convenience in a special brick mode.
It is much easier to count the points now![/quote]
I don’t understand what do you mean, sorry
This should be funny.
It’s broken in 2016r4 and I expect them to fix it for 2017r1.
Do not hold your breath 'till its release
Can anyone confirm if that 2017r1 fixes this issue? It would seem the ‘GraphicsPrintingExample.xojo_binary_project’ demo project still isn’t working right in 2017r1. The printer resolution is reported as 96dpi with 2017r1 while with an older IDE, such as e.g. 2016r3 it reports 1200dpi for the same printer.
Shorts is working with 2017 R1 so I know that printing is working. I suspect they didn’t update the example project.
Yes- it is reporting 96 DPI for layout purposes in the new printing engine, but the end output from drawing operations like DrawString, included example projects like PrintingPicture, etc. should be fine and at the appropriate resolution that your printer can support.
Yeah, that’s not going to help with my project, through, where I need to be able to accurately calculate the scaling factor. Up until now the scaling factor was 16.6667 for a 1200DPI printer. Now it’s 1.333. My project plots X-Y graphs, and in order to plot as accurately as possible, my code draws the data to a picture that is scaled up by the scale factor and then draws the picture to the printer graphics object. If the printer only has a resolution of 96DPI, even through drawing directly to the printer graphics object might sharp looking results, the positional accuracy for data points is now over 10 times worse than before. So, what options are there now to determine the maximum resolution a printer is capable of? Previously, setting the MaxHorizontalResolution and MaxVerticalResolution to -1 would result in the HorizontalResolution and VerticalResolution being set to the highest resolution the printer can handle. Now it’s set to 96DPI regardless.
I can see that could be a problem for print high resolution graphs from the MBS Chart Director plugin.
- Karen
Try using the ScaleX and ScaleY properties on the graphics object. If you do that, be aware that they can get reset after calling NextPage.
Thanks. Unfortunately ScaleX and ScaleY are both 1 for the graphics object returned by OpenPrinterDialog on Windows 
2016R3 is the solution for the moment.
Does the old hack still work?
Create a picture 4 times the size of the actual page at 96dpi , draw onto that, and use drawpicture to render it onto the graphics offered by the printer.
Ive been using this as a reliable workaround to printer resolution issues for years
[quote=323510:@Jeff Tullin]Does the old hack still work?
Create a picture 4 times the size of the actual page at 96dpi , draw onto that, and use drawpicture to render it onto the graphics offered by the printer.
Ive been using this as a reliable workaround to printer resolution issues for years[/quote]
Yes, this still works. You have to be careful on how much you scale up the image, though. I found that you end up with an empty page if you scale it up too much. A factor of 16.6666 for a 1200DPI print used to work before, but now it seems I can only go to a factor of about 8. Higher scaling factors result in a blank page. I have only tested this with a few printers, though. I might be that this factor is limited to the resolution the printer can handle. 600DPI corresponds to a factor of 8.3333. I think it may be necessary to limit the scaling to a save value that works with all printers, or let the user select from a list of common resolutions and calculate the scaling factor accordingly. a factor of 4 corresponds to a little less than 300DPI. For most use cases that should suffice. I will probably have to live with that for now or compile with 2016r3 if I want to take advantage of the full resolution a printer can handle. For plotting data, 1200DPI looks significantly better than 300DPI.
I meant altering the scale properties, like:
g.ScaleX = g.ScaleX / 2.0
g.ScaleY = g.ScaleY / 2.0