[x] I agree to follow the Code of Conduct that this project adheres to.
[x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Describe the bug
When exporting a drawing to PDF using the "Export as" menu, if you use the "crop" method, whatever is the largest object in your drawing will define the size of the exported document... PLUS 0.96pt aka 0.013333333333 inches.
This value seems to be static regardless of the size of the object being cropped to, and does not scale if you export a huge document or a tiny one. This also seems to be present even when the object being cropped to has no "line" aka only a fill.
The "point" unit I am referring to I do not think is related to the "points" unit in DrawIO since when I export - for example - a rectangle sized to US Letter document: 850pts wide by 1100pts tall, the PDF viewer program I use (PDF X-Change Editor) shows it's size as 612.96pt x 792.96pt whereas if I create a rectangle twice as big in DrawIO (1700pts wide by 2200pts tall) PDF X-Change shows it as 1224.96pt by 1584.96pt
To Reproduce
Steps to reproduce the behavior:
In a blank document (preferably in an incognito tab), add a rectangle.
With the rectangle selected, uncheck the "Line" checkbox in the "Style" panel.
Change it's size to 850 pt wide by 1100 pt tall in the "Arrange" panel.
Under the "File" menu, choose "Export as" and then choose "PDF".
In the PDF Dialog, choose "Crop" (instead of "Page View" or "Fit to")
Make sure the "Border Width" is set to zero and "Zoom" is set to 100%.
Click "Export" and view the PDF in Google Chrome or a PDF editor.
View the document size. In Chrome, you can click the three dot menu in the upper right corner (next to the "Print" icon) and choose "Document properties"
Note the document size is "8.51 x 11.01" as seen in Google Chrome or equivalent measurement in other PDF Viewers.
Expected behavior
Document size should match largest object size (assuming there is no edge line that adds half of said line's thickness) when exported and cropped.
draw.io version (In the Help->About menu of the draw.io editor):
draw.io version 24.7.8
Desktop (please complete the following information):
OS: Windows 11
Browser: Google Chrome
Browser Version: 128.0.6613.114
I tested the problem in incognito/private mode with all browser extensions switched off, write "yes" below:
yes
Additional context
This may or may not be related to another reported bug: https://github.com/jgraph/drawio/issues/4520 but I'm not sure how, since that is a scaling issue (multiplicative) and this is an issue of addition.
Preflight Checklist
Describe the bug When exporting a drawing to PDF using the "Export as" menu, if you use the "crop" method, whatever is the largest object in your drawing will define the size of the exported document... PLUS 0.96pt aka 0.013333333333 inches.
This value seems to be static regardless of the size of the object being cropped to, and does not scale if you export a huge document or a tiny one. This also seems to be present even when the object being cropped to has no "line" aka only a fill.
The "point" unit I am referring to I do not think is related to the "points" unit in DrawIO since when I export - for example - a rectangle sized to US Letter document: 850pts wide by 1100pts tall, the PDF viewer program I use (PDF X-Change Editor) shows it's size as 612.96pt x 792.96pt whereas if I create a rectangle twice as big in DrawIO (1700pts wide by 2200pts tall) PDF X-Change shows it as 1224.96pt by 1584.96pt
To Reproduce Steps to reproduce the behavior:
Expected behavior Document size should match largest object size (assuming there is no edge line that adds half of said line's thickness) when exported and cropped.
draw.io version (In the Help->About menu of the draw.io editor):
Desktop (please complete the following information):
I tested the problem in incognito/private mode with all browser extensions switched off, write "yes" below:
Additional context This may or may not be related to another reported bug: https://github.com/jgraph/drawio/issues/4520 but I'm not sure how, since that is a scaling issue (multiplicative) and this is an issue of addition.