SynEditPrint using DirectWrite

[pyscripter]

I have started the DirectWrite implemention in the the branch DWrite.
So far I have completed the implementation of SynEditPrint using DirectWrite. It now handles WordWrap correctly and the code is much simpler (25% less code).

@MShark67 @JaFi-cz Could you please test using the new Print/PrintPreview demo?

[JaFi-cz]

How is it with DirectWrite and Windows XP support?

[pyscripter]

Have you tried printint/print preview with the DWrite branch?
It should not work on XP.

[JaFi-cz]

Thank you for answer. I will start to work for end of WinXP support.

[MShark67]

I've checked out the demo and it works on my Windows 11 test machine. I ran into some issues integrating it with my homemade print preview system which is based on TMetaFileCanvas. I suspect that DirectWrite isn't compatible with it. I wrote it so long ago that I can't remember why it uses that technique, so it's probably time to look into updating it. I can definitely see that DirectWrite has some nice advantages, and that your changes fix the "wrapped last line on page" issue that I had a rather poor workaround for. Nice!

[pyscripter]

@MShark67 Thanks.
I was aware about the the aliasing issue and I will look into the printing issue.

[pyscripter]

The printing to printers is now fixed. Tested only on XPS and PDF printers.
I am now looking at the text rendering quality.

[MShark67]

I can verify that the new version works for printing on my HP Officejet. Nicely done! The change also makes it possible for this to work with my MetaFile based printing system. Would it be possible to change the three "if FPrinting then" checks in PrintPage(Num) to:

if FPrinting or (FCanvas is TMetafileCanvas) then

-Mark

[pyscripter]

Will do. Is the print quality good?

[MShark67]

It does look good! I printed a page using the non-dwrite version and this new version and the individual character quality looks identical. The spacing between letters is very slightly different such that the dwrite version slowly shifts the letters to the right as you go along the line (so perhaps the spacing between letters or the space character itself is slightly larger using the dwrite version.) I assume that's just minor differences in the new layout capabilities and I'm mentioning it just for completion.

[pyscripter]

I have found a way to resolve the preview text rendering quality issues. I think it is now OK.
@MShark67 @JaFi-cz Please check it out.

This was a good opportunity to learn how DirectWrite works. I can now move to the DWrite implementation of SynEdit.

[MShark67]

It's definitely an improvement. I do notice that when comparing the header text to the "body" text (when set to the same fonts) that the header characters are "more aliased"/clearer than the dwrite characters, but it's certainly good enough for a print preview. The redraw performance of the preview seems an issue, so I wonder how that will translate to the editor itself (but perhaps it's just the scaling/mapping that causes that.) On a side note I noticed that long lines without any break characters cause the line to be drawn on a single line and clipped instead of being wrapped. That may be "as intended" but I thought I'd mention it as my corner case test files include lines like that.

[pyscripter]

Fixed the long word wrapping issue. Please test.
I have also tried a non GDI-compatible text layout, which I think improves slightly the quality. See the commented lines in TSynTextLayout.Create. Can you give it a go (uncomment first two lines and comment the following three) and report whether it looks better?

Regarding performance it will not be an issue (I think). In SynEditPrint there is a massive amount of scaling/mapping involved. Also the implemented solution is not the most efficient one . There is a lot of creating, copying and scaling large bitmaps at printer resolution behind the scenes. (Create a large bitmap the size of a page, assign it to a WicImage, Draw on the WicImage using Directwrite, then draw the WicImage on the Canvas (which is in anisotropic mode) using GDI which converts it back to a bitmap. It was just a convenient way to get the needed results and keep most of the existing code. There is a lot of scope for making it more efficient but I think it is good enough. None of the above is needed for rendering the text in Synedit.

[MShark67]

Wrap fix works perfectly! I don't see any major quality differences between "regular" and "gdi compatible" TextLayouts, even when zoomed in (I hope I'm testing it correctly, I think I am, I just don't see any obvious difference.) I think this new version doesn't need the TMetaFileCanvas checks anymore since the change to use WIC instead of the canvas directly makes it TMetaFileCanvas compatible.