Add native PDF output support #2882
Conversation
Test Results 162 files - 14 162 suites - 14 28m 9s ⏱️ + 1m 10s For more details on these failures, see this check. Results for commit 433898e. ± Comparison against base commit e21a57a. This pull request removes 94 and adds 2 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
laeubi
force-pushed
the
add-pdf-support
branch
3 times, most recently
from
060ff6c to
d27eb11
Compare
It seems I am that guy. :-) Sorry I don't know what that means or how to fix it. |
Your first need to rebuild the natives there is a "Build-SWT-native-binaries-for-running-platform" run configuration in the repository for that purpose https://github.com/eclipse-platform/eclipse.platform.swt/blob/master/bundles/org.eclipse.swt/Build-SWT-native-binaries-for-running-platform.launch this should then give you the required new bindings in the swt fragment. |
|
I built the binaries but there is a native crash when running the Snippet. Here's the interesting part: |
|
The crash happens when calling The line in GC that triggers the crash is line 1012: if (drawable != null) drawable.internal_dispose_GC(handle.id, data);And if I comment out that line I still get the same PDF. So perhaps two things here - a crash and not drawing to the GC? |
|
@Phillipus thanks for the testing, I'll see what I can do here! I suspect we have a similar problem as on widnows that shell.print is simply not implemented... |
|
Three things then on Mac:
I copied and pasted all the GC drawing code into the main |
|
@Phillipus many thanks at least it looks like it generally works 👍 |
|
I just tested the latest PR. The crash on |
I should have checked :-) public boolean print (GC gc) {
checkWidget ();
if (gc == null) error (SWT.ERROR_NULL_ARGUMENT);
if (gc.isDisposed ()) error (SWT.ERROR_INVALID_ARGUMENT);
return false;
} |
|
Latest PR seems to be working. Still flipped image, though. |
Great thanks for the fast confirmation. What do you think about the flipping, is it a bug of macOs (and weh should maybe wait for a fix of apple) bug of SWT... or just "normal behavior" in wich case I would just try to apply a transformation here. I read through the referenced bug but I'm not sure what would be the correct fix in this case... Maybe I need to handle isFlipped somewhere in the PDFocument? |
Hard to say. In the case of that bug it was eventually resolved by Apple but there's no guarantee when/if/how long Apple resolves these things. There may be something in the cocoa API that needs to be set to unflip the image. This works: graphicsContext = NSGraphicsContext.graphicsContextWithGraphicsPort(pdfContext, false); // Set to false |
But now exchanges Top/Bottom controls and text is painted to the bottom :-D I wonder if/how it looks like if one export a composite/shell to a PNG image ... |
|
But |
laeubi
force-pushed
the
add-pdf-support
branch
from
57c1f7f to
cfe4a6c
Compare
|
I think this is now basically in a state where it could be merged (if no one further objects) and we can improve on any further issues with additional PRs. |
Can you please add smoke test that creates a PDF document printing "hello world" to it, saving to file & checking that PDF is not empty (or something like this)? Also dispose() should be tested. |
Currently if one wants to create a PDF file it requires external libraries and as SWT does not allows an abstraction like Grahics2D in AWT one can not export real content of SWT components (e.g. Canvas) except exporting as an raster image or using some hacks. This now introduce a new PDFDocument to enable direct PDF generation from SWT widgets via Control.print(GC). This allows applications to export widget content to PDF files using the standard GC drawing API as well as even creating completely customized documents.
Currently if one wants to create a PDF file it requires external libraries and as SWT does not allows an abstraction like Grahics2D in AWT one can not export real content of SWT components (e.g. Canvas) except exporting as an raster image or using some hacks. This now introduce a new PDFDocument to enable direct PDF generation from SWT widgets via Control.print(GC). This allows applications to export widget content to PDF files using the standard GC drawing API as well as even creating completely customized documents.
The macOS implementation was just returning false without printing children, similar to a previously fixed Windows issue. Now it properly iterates through child controls and prints them with correct coordinate transformations using NSAffineTransform and NSGraphicsContext state management.
laeubi
force-pushed
the
add-pdf-support
branch
from
5695f46 to
433898e
Compare
3 participants
Currently if one wants to create a PDF file it requires external
libraries and as SWT does not allows an abstraction like Grahics2D in
AWT one can not export real content of SWT components (e.g. Canvas)
except exporting as an raster image or using some hacks.
This now introduce a new PDFDocument to enable direct
PDF generation from SWT widgets via Control.print(GC). This allows
applications to export widget content to PDF files using the standard
GC drawing API as well as even creating completely customized documents.
Platform Support
I currently have only tested this on Linux GTK, I currently have no way to test it with Cocoa (macOS) it would be great if someone with a mac can take a look. I'll try to take a look on windows soon but also here some help would be appreciated!
The Snippet388 can be used to produce such PDF after compiling the natives with the "Build-SWT-native-binaries-for-running-platform" run configuration.
GTK (Linux)
On GTK (Linux) the snippet looks like this:
And here is the resulting PDF document:
Win32 (Windows)
On Win32 (Windows) the snippet looks like this:
Due to the usage of the pdf printer that do not supports custom page size, we have the limitation to not getting perfect page sizes and we currently try to find the best matching one, the PDF document then looks like tihs:
As an interesting observaation I found that Shell#print is not implemented for windows (simply returns), I added an implementation for this as well, but this part is maybe better submited as an own PR.