Menu
▾
▴
1 Attachments
#300 Words squish together
Words squish together in print screen (and printed copy) to get words aligned under chords whenever a chord is towards the end of the line.
Windows 10
Version 3.4.8
Related
Support Requests: #300
Support Requests: #345
Discussion
Anonymous
Hi, I am aware of this ugly, bad rendering on screen. Unfortunately I do not know how to fix it without breaking the preview in other ways.
The page is rendered using vector graphics. Unfortunately, the framework does not provide any means of getting the width of a text string in vector form. Therefor we draw it with a large font size as to mimic the relatively high dpi value of a printer in comparison to the screen. Text fragments are placed according to these widths. This sometimes leads to these overlaps or, less frequently, too wide gaps between stretches of text. This, according to my observations, goes away with larger renderings, both in the preview, using the zoom level, and also in print (using higher dpi values than the screen). Note that this happens drawing the exact same vector representation of the page. This leads me to think the error is with the rendering, not with the vector representation. If anyone knows how to solve such a thing, please tell me.
Do you really experience this on print also? If so, could you please provide me with your preferences.plist which is located in %APPDATA%\OpenSong.
If your printer does not render the page correctly indeed, please try to print to the PDF or XPS printer first to a file, then print that file. Does that help?
Thanks for the screenshot that includes your source. That makes it easier to reproduce the issue and have an example for testing possible solutions.
As indicated in the previous response, the way OpenSong composes the printed page is somewhat suboptimal. Some of our calculations for character and word spacing need to be improved. I am currently looking at another issue in the printing subsystem that may be related and so I will look into this at the same time.
As a workaround, you may wish to try using the Export feature to create an HTML file you can open in a browser and print from there.
What would be more helpful than the preferences.plist is the PrinterSettings file that will be in the Settings folder where your OpenSong data is stored. PrinterSettings includes the font and size data OpenSong uses to compose the page.
A couple of things to look into:
Hi Ed,
the problem can be seen in most example songs with default settins as by
the installer.
before you look into this too deep - I discovered that the shipping
version appears to have an additional bug regarding this compared to my
working copy. I will try to extract, what I might have fixed, and
whether it is fixed in your branch also.
Anyway, at least some of the problems come from the fact that the length
of text rendered from a TextShape differs depending on the Graphics
surface you are rendering it to. Font features might be to blame
partially, but that does not solve anything. Neither does is help to fix
the issue.
I think we cannot use TextShape at all, if we want to avoid this. We
needed to render the page as pixel graphics, so we hopefully can rely on
TextWidth (hopefully). This woul likely result in much inferior PDF,
XPS, EMF, PS prints and generate much more data. Moreover, the print
must be rendered again when printing from preview, and as a result,
still look differently printed than on screen. Maybe switching Object2D
to the PDF API would help, but I don't know that API yet.
Am 08.08.2022 um 03:08 schrieb Ed Palmer:
Related
Support Requests: #300
Interesting. You say that the example songs on the default settings show this behavior. As a test, I created an absolutely clean Windows 10 VM, built my branch (with some local changes that do not affect this part of the printing algorithm), created an installer, and ran it in the new VM. I tried all of the example songs with Letter paper size and one-inch margins as well as A4 with 2.5 cm margins and everything in Print Preview appears correct. I printed some to both my printers (an old LaserJet and a Canon inkjet). While the output doesn't exactly honor the margins set in the Print Setup dialog, the overall output is legible without the compressed sections seen in the original post.
I am not denying that there is a problem, just stating that I am having difficulty reproducing it using the tools I have at my disposal.
I have been investigating the PDFDocument object Xojo added to the framework last year, especially since print to PDF is a desired feature especially with Mac users. I have the basics working with two different approaches. Since I started on this before Xojo 2022r1 came out with support for Group2D/Object2D for PDFDocument, I wrote support routines in the GraphicsX module to convert Object2D items to their raster equivalent. I have a separate version that uses the Xojo builtin support. I have not yet committed those to the repository; perhaps I should do that. They are both similar in the output they produce on the Mac. I am finding some inconsistencies in how it works on Windows. I have not yet fully investigated Linux. At this time I have to say that it is not a viable option for Windows without resolving the issues I see. (Side note: I have already submitted one bug report to Xojo for the CurveShape on PDFDocument).
Regarding moving to raster output: I am not opposed. I do not want to completely give up on a vector approach if accuracy can be guaranteed. We may need to have platform-specific code to account for differences in the rendering engines. For example, the TextWidth function on Mac returns a true double when used with a canvas control, picture object, or PDFDocument. On Windows, the PDFDocument returns a double but it is really an integer because there is not a fractional part.
OpenSong started off using the raster functions. The print preview zoom looked really bad at larger scale factors, so it got rewritten. This was all prior to the initial commit to the current SVN repository so there is no history. That is the reason both raster and vector functions exist in GraphicsX that have similar argument lists.
OpenSong has a lot of room for improvement here. Printing has always been the weak spot. I have dreaded having to get in there to work on it and it may be easier to do a total rewrite than continue to patch what is there. Any ideas would be welcome.