You wont scale a picture, you’ll scale dozens of contents, font sizes, x,y coordinates.
What about a lazy “one design fits all (kind of)” approach for letter and A4. See:
One could design just one A4 landscape report, and printing it as is for Letter, except scaling it down to 94% in one step, not all 1000 items on such page one by one.
Have you tried Xojo Reports (and its Designer)? I’m not sure if we have options for best fitting things designed there.
I havent tried the Xojo reports myself, but the Unit setting seems to be the answer:
Description
Used by the Reports Module module to specify the Units used in creating/modifying the report.
Values
Enum
Value
Pixels
0
Inches
1
Millimeters
2
If you expect the page is 8 inches across, and specify column widths which add up to 8 inches, I would expect the output to take account of the printer size and resolution, to produce an 8 inch output. (But not having used reports, I don’t know for sure here)
Is the Emile’s report defined as being 14 inches in size, so as to require shrinking by 55% to fit on an 8inch page?
Or 20 inches wide so as to fit on landscape paper which is 11 inches across?
I used a bit. And the answer is NO. Not even close.
I had reports designed and working on PC, and the same report on a Mac caused troubles.
Not a good experience. I don’t remember the details, but I remember that if I could read the Mac settings and scaled the report a bit, it would fit, because in the Mac I had no margin controls, just scale. And If I made the report for Mac it would differ on a PC. Displacements occurred tied to the platforms and not being able to read and adjust settings by code.
I remember that I worked around the problem, and I HATE workarounds. In the Mac the workaround was saying in the manual the scale detail. In the PC I could detect the margin settings wrong, presented a message saying the user to set the 4 margins to 0, and the report designed to A4 full width with few millimeters of safe blank margins by design worked ok.
And what Emile is doing I have no clue. Sometimes he does things in… unique ways.
What I do:
I set a Tab() array and fill the values where I want to start printing each column (from the ListBox or SQLite Fields),
Then, after printing a heading (presentation) page, in a loop where I count the number of lines, I print each line, Column after Column using Tab(x).
No magic, nothing fancy. Maybe not the old school way, but works fine when printed using a MacOS and resizeing to 55% (with a 14 Columns Record / that kind of data).
NB: I shrink the string to a predefined # of characters, adding an ellipsis (…) at the end.
Is there something wrong in this printing design ?
My user never reported a problem there; he printed from the macOS version, printing on different technologies (inked low cost printers to Laser Printers). His only report was because the age of the readers (too small to be read by oldsters).
He even printed the list in A3 papers (2 times A4). He do not knew there was a trouble with Windows (XP thru 10).
But the rule of thumb is: If the dev is satisfied with the “how to”, and even more important, if the users are satisfied with the product, things are valid.
Things vary depending on parameters, in this specific case I would say:
rule(Emile, his_specific_user, “report needing manual adjusts outside the app to run”) =
rule(Rick, any_user, “report needing unusual manual adjusts outside the app to run”) =
Are you drawing the strings to graphics via g.DrawString? If so, you can scale everything down in your code by adjusting the Tab() positions and the font size.
In fact, I had to go to the medicine woman yesterday and in the transportation I was thinking to use a Scale Factor value and add that to my code like you wrote above.
I will experiment that later today if I can get time to do it.