Graphic Plus Save Bitmap PPI Resolution

[inno]

Hi @DavidMans,
thanks a lot for the great plugin, I’ve been using it a lot in the last weeks and it’s just AWESOME

I’m bothering you because I don’t fully understand the behavior of the Save Bitmap → Resolution value

With the following very simple setup I’m drawing a square with side 1 unit, a random stroke just to make the square appear, and I give the drawing a boundary equal to the square itself (so the thickness of the square will look like half of the value I set, only the “inward portion” will be visible because the “outward half stroke” gets trimmed out of the drawing boundary)

GraphicPlus_PPI_Resolution_Question.gh (14.3 KB)

as very last thing I set the drawing units to inches (index 6) and the Save Bitmap resolution to 300 PPI

the svg file is just perfect, when I open it in a vector editor software it has all the features I would expect, pure magic:

center of the square is at 1/2 inch (12.7mm) on both X and Y
side length is 1 inch (25.4mm)
stroke width is 0.2 inches (5.08mm)

the very same shape saved as 300 PPI -in any format- outputs a 4x4 pixel image, and I can’t understand what I’m doing wrong

because the PPI resolution is set to 300 pixels per inch, and the drawing size is set to 1x1 inch, I would expect to get images of final size 300x300 pixels

I understand the theoretical difference between DPI and PPI, which is basically related to screen visualization resolution and printing resolution, but I can’t wrap my head around it

when I plug the Drawing Viewer, the preview gets super tiny and consistent with the images that are saved:

All this leads me to think there’s something that I’m obviously not able to catch… any help or insight would be much appreciated!

[DavidMans]

Thanks for pointing this out!
Units were added recently as a quick patch for someone who was working on a CNC machine.
I just updated the resolution settings for someone who wanted to make images at a resolution lower than 72 dpi.
Both of these were a bit hacky, and I need to clean them up.
Chances are units are not being recognized in the unit conversions.

Let me take a look over the next few days and see if I can put out a more stable release that behaves as expected!

[inno]

oh wow! thanks a lot!

[inno]

Hi @DavidMans, I’m still succesfully using Graphic+ 1.8.11 and I have found a way around for getting resolutions that are very very close to what I need from time to time (it involves a bit of trial and error, but it works fine )

I’m in front of an unexpected behavior for text built on rotated planes that I am not able to solve/understand

I have reproduced the issue in this very much simplified definition:

Graphic+ text on XY rotated plane.gh (19.9 KB)

I build a triangular grid, and in the center of each triangle I build an XY plane on which a text is created showing its progressive index number
I then add a thick rectangular edge-contour to the whole drawing, and preview / save as image file

if the planes created on the triangle centers are XY_planes, then everything works fine regardless of the resolution used to preview/save the image file:

comparing different resolutions (images are downscaled just to compare features)

but if I rotate each plane (for instance) 90 degrees clockwise (-Pi*0.5) then the bottom part of those text entities disappears both on the GH preview and in the saved file, and the higher the resolution, the more portion of the image disappears:

if plane-for-text rotation is set to -45°, this happens for different resolutions:

one maybe important detail, in both the above rotation examples, the trimming of the image does not happen on an entity basis, meaning a text entity is either present or not, but it just gets deleted and sometimes pixel appear misplaced like in the following:

this issue is not present when saving as svg