This is just a public service announcement for windows users.
Don’t turn this into a “why now and not a year ago” thread, just go here and vote for it if you want it.
Julian, I don’t understand… From reading the other threads about that, it seemed that now there was the concept of “virtual printing space” where one could send a picture with the same resolution as the printer.
So even with you recent work to detect the resolution of the printer, it will still print at 96 dpi ?
I have not started experimenting, though, but if indeed we remain limited to 96 dpi with printers like 1200 x 1200 dpi, it is really unfortunate.
My thoughts (in order):
Facepalm
Stupid.
They are turning Xojo into a real toy language.
Dumb. Dumb. Dumb.
Sorry, but Im flabbergasted.
that’s correct.
no, it won’t be restricted to 96 dpi.
you can draw object2d (1) in that “virtual 96 dpi layout”, and it will print crisp and sharp. or you squeeze a high resolution image and DrawPicture (2) it in the virtual layout, and it will show as expected on the paper.
(1) good here: you can use doubles to draw hairlines
(2) notice: you need to use all parameters (DestWidth/Height of the virtual 96DPI layout; SourceWidth/Height of your full resolution Picture)
the biggest issue is people who are using a simple (Print-96dpi-virtual-layout)Graphics.DrawLine. Why? Because we only get to use Integers here… so the smallest/thinnest line will be a 1/96 inch thick line. Which certainly is thicker than a hairline you can draw with Object2D or before (on a 300/600 dpi print Graphics).
One of the webinar topics I suggested to Paul was how to do printing, and especially high-resolution printing, in Xojo
[quote=376391:@Michel Bujardet]Julian, I don’t understand… From reading the other threads about that, it seemed that now there was the concept of “virtual printing space” where one could send a picture with the same resolution as the printer.
So even with you recent work to detect the resolution of the printer, it will still print at 96 dpi ?[/quote]
Yes and no on the virtual space. Yes because it would translate from 96dpi to the printers target res and no because they wouldn’t be sent at the printers native rez. It’s a bit hard without drawings to explain, let me try.
Essentially, the D2D canvas we’re drawing onto is 96dpi for the sake of placing things in positional space. So on an inch by inch piece of paper the left side is 0 and the right is 95. If the printer then can print in 300dpi those points would then translate into 0 to 259. This is one of the fundamental issues with the standard drawing routines, they are integer based so there is no way to position things exactly because when they ended up on the printer the would be 3 units apart. A dot a 0,0 and 1,0 would be translated to 0,0 and (300/96=3*1=3) so 3,0. This would also mean that your 1 pixel wide line at 96dpi would end up as 3 units wide on the printer and look terrible. If you used Object2D you could place things from 0.0 to 259.0 as scale factor from 0.0 to 95.0 (if that makes sense) which I assume Xojo was advising people to do if they had printing issues and raised a ticket about it.
So for “bitmaps” if you had a 96dpi image at 0,0 it would take an inch up in D2D and and inch up on the printer, however when printed it would be low rez so we’d need to increase the image size by 3x (300/96) to have it print at native rez on the printer. This was one of the fundamental issues you and others were having when not being able to detect the device dpi, how did you know how much to scale the image by to have a nice print at native resolution without going overkill and sending over a 10x image on the off chance that the printer had less resolution than that.
I have many theories about why this was done but I’m not going to go into those as they are pure speculation and it might get the thread locked. I think Xojo knows there is a problem and I’m glad they are looking at it.
I was in the process of making this video/ticket when 51556 appeared.
It’s like flicker gate, but for printing 
Wow, <https://xojo.com/issue/51556> has already been implemented, someone get a bucket of water, WIlliam is on fire 
I guess we don’t need to vote for it then.
I’ve been doing that for the last 12 years anyway.
It’s been so long since I started doing it, that I forget what the original problem was which I was working around!
Lending support to the old adage about temporary workarounds becoming permanent features…
Thank you Julian.
Printing has always been in all computing history one of the most annoying things to do. Especially under Windows, where there are gazillion of different printers. A good friend of mine developed a great number of drivers for the early Windows back in the eighties, and I was amazed when I saw the work he had to do to accommodate each printer idiosyncrasies.
Indeed it is no point to lament on broken code, as painful as this can be, if we can get at least back to something usable. In that respect, your work with DEVMODE could be implemented internally for Xojo to report the actual resolution, as it was in the past, instead of always 96 dpi. Would that not be a good idea to file a feature request ?
I also feel the LR has now become vastly inadequate when printing is concerned. It needs an overhaul.
Indeed printers are a nightmare, thankfully the closest I got to them was writing an activex control to print a receipt from a web page for an in store kiosk.
I don’t think there’s much point until the next alpha is released and we can see what/how <https://xojo.com/issue/51556> has been made available to developers. It might be exactly what is needed
You’re kidding ?
Nope, I was proud of that hack too 
This was about 18 years ago mind you, it was the wild west back then
This is good news already