Units pixels points and mm
Dear community,
I stumbled on the question of units inside the NodeBox application. What is internal logic of handling them?
I was assuming that number for height for example is the abstract unit. The only question then is when I export the file to svg i get pixels and in pdf case - points. I was thinking to make some kind of recalculation inside the NodeBox file pt-mm, but maybe it is unnecessary. Thank you for the help!
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by john on 16 Apr, 2019 06:19 PM
Hi Gizys,
NodeBox is an entirely vector-based application so the pixels referenced in various node serve only as a relative size reference. Relative to what? The canvas - as defined in Document Properties under the File menu.
The canvas width and height determines the final output dimensions when you export a PNG or the size of each movie frame if you export a movie. PDFs and SVGs are also vector-based, so in those cases the canvas serves mostly to establish a default size and the overall proportion of width to height.
If the PDFs or SVGs ever get printed (scaled to fit on a postage stamp or billboard) the extremal app you use will determine how many pixels ultimately get printed and how many inches or millimeters they get scaled to.
So from inside NodeBox the pixels only serve only as a reference to measure how much wider one rectangle is than another, or whether a font seems big or small compared to other elements around it.
If you know in advance that you are going to create a poster of a certain physical size at a certain resolution (e.g. 300 dpi), you can calculate the number of pixels involved and size your NodeBox canvas accordingly. In that case you could make a node to convert desired inches into pixels and use that to size your elements, but this would only apply to your own particular project.
Does that help?
John
2 Posted by willadams on 22 Apr, 2019 01:07 AM
I would like to use Nodebox to prepare files for a CNC machine.
Entering 100 as an input dimension, I'd like that to yield 100mm, but when I add a scale node, it truncates my scaling factor of 376.676209 to two digits, so I get 99.663 millimeters.
Is it possible to get better precision?
3 Posted by jerimee.richir on 24 Apr, 2019 02:04 AM
A quick (and largely unnecessary) screenshot to show File > Document Properties
Support Staff 4 Posted by john on 29 Jun, 2019 06:52 AM
willadams,
I was just cleaning out our forum and found your note. It was mistakenly marked as spam. My apologies!
If you are still there and still need help, let me know.
John
5 Posted by willadams on 29 Jun, 2019 12:16 PM
Thanks for mentioning that --- the problem with that is that it requires a specific setup in advance, and would mean that two folks running the same file would have different results, which isn't something I can support, or am willing to work with.
Which is unfortunate, since the software is well-suited to my needs otherwise.
Support Staff 6 Posted by john on 29 Jun, 2019 09:29 PM
Will,
When you enter a value into the scale node (or any other port that accepts a floating point number) the dialog only displays the first two decimal numbers. But the entire value is actually stored.
I did a few simple experiments. I scaled a 100 unit width rectangle by 376.676209 and then measured the resulting width. It was 376.676209. I tried a few other variations and was unable to replicate the rounding error you mentioned.
No doubt your setup is far more complex. I would have to see it to determine where the rounding errors creep in. But in principle I think you should be able to scale to the normal limits of the float data type which should easily handle your six digits of precision.
If it turns out that the float data type offers insufficient precision for a chain of calculations it may be possible to create a custom node to do those calculations using Python's decimal data type for arbitrarily high precision.
As for producing consistent results from a single NodeBox file even over different setups, I think you could also handle this by importing a CSV containing the details of each setup. The NodeBox network could take that into account and adjust accordingly.
I can't be sure without knowing exactly what you are trying to do, but with the information I have I don't see why NodeBox couldn't provide the precision and consistency you need.
John
7 Posted by willadams on 29 Jun, 2019 09:32 PM
My setup was multiplying by the numbers mentioned with the results cited measuring the geometry in the generated PDF by opening it in vector drawing program.
Support Staff 8 Posted by john on 29 Jun, 2019 10:03 PM
Ah.
As I said, the precision within Nodebox is fine. But when I tried exporting my test output to SVG the values were rounded as you said. The pdf is a little harder for me to see, but I presume it incorporates the SVG rounding.
You can confirm this by peering inside the NDBX and SVG files with a text editor. Precision is conserved in NDBX and rounded in SVG.
My understanding is that when you save an SVG you have the ability to specify precision. It is common practice to limit this in order to keep the resulting file size manageable. My guess is that NodeBox defaults to a low precision when exporting SVGs and PDFs.
Adding Frederick. Frederick, can you confirm that this is the current NodeBox behavior. Can you think of a way Will could override the default precision when exporting a PDF?
I think it should be possible to create a custom high-precision export node, but this could be quite an undertaking.
John
Support Staff 9 Posted by john on 29 Jun, 2019 10:13 PM
Frederick,
Looking at the SVGRendered.java code on NodeBox Github I see this at the top:
public static String smartFloat(double v) {
if ((long) v == v) {
return String.valueOf((long) v);
} else {
return String.format(Locale.US, "%.2f", v);
}
}
Is this what is causing the rounding on SVG export?
John