Floating Point in BB

I am wondering whether a floating point BB would affect the performance of a font?

What does “BB” mean?

I abbreviate Bounding Box - BB

You mean a grid setting other than 1? To my knowledge, there are no performance issues, except that PS-based WOFFs may end up becoming slightly larger. There have been PDF issues with recent versions of Quark XPress.

1 Like

I recently worked on a complex autotraced font with floating point coordinates. Performance was fine, although I limited my testing to short bits of text because it’s a headline font for ads. I did run into performance problems in Glyphs, which was a little slow trying to update the font and render it on my 5k display. But that seems normal—glyphs with hundreds of points at insane resolutions is definitely an edge case.

1 Like

Awesome, guys! I am so happy to hear that [smile]

Did you have many small curve segments? Or was it just straight line segments?

It was a mix, probably 95% straight segments and another 5% curves.

I’m also looking at floating points for some rounded corners. What are the exact issues with Quark Xpress?

When you export PDFs in XPress (tested in version 6.5 and 2015), there can appear a small offset at the closepath position of a contour. Here is an enlarged screenshot taken out of a PDF generated in XPress 2015:

This appears both with text set inside the XPress document, and with (InDesign) PDFs placed as image in the XPress document.

This has been reported to Quark, and the reply from support was that they considered it ‘minor’. So, I do not expect Quark to fix this anytime soon.

1 Like

Thanks Rainer. Also somewhat related, when using grid spacing of zero, some of my spacing values – those derived from others by means of percent (i.e. =h*0.75) does not round, and produce a warning triangle. Is there something like round() in the spacing calculation fields?

Sorry: Questions keep popping up. Is it possible to only allow handles to use decimal positions, but keep points rounded to the integer?

That should be the default for any non-one grid.

IIRC advance width cannot be a decimal, so if you multiply with a decimal value, the calculation cannot be fulfilled.

This is my setting. The nodes does not round to integer. For example, the results after scaling with RMX tools:

Guys, I think you are doing a great job, but you sometimes leave me very confused. I know multiplying a decimal value most likely will not produce a round number – thus, I’m asking if there is some way to round it. You didn’t answer my question, but rather one I didn’t ask :confused:

There is no round function for the metric keys. What is stored in the OpenType font is the LSB and the width. The width is always an integer at export time. IOW, the width is always rounded, the RSB is not even stored in the font file.

Grid step 0 is equivalent to grid step 1 with a subdivision of 100. This will also cause the use of the div instruction in the CFF, which in turn will cause XPress to misbehave as shown above. The only setting XPress can handle is grid step 1, subdivision 1.

Thank you. That answers my question.

By the way: Quark Xpress can handle larger UPM values, though anything other than multiples of 1000 produce spacing errors. (I cannot remember where I read it, ATM.)

Yeah, true. It can also handle larger grid steps, since they don’t export as such into the final file, as long as they don’t trigger the use of the div instruction (I.e. As long as subdivision <= grid step)

EDIT: it should be: as long as grid step ÷ subdivision yields an integer value, then no div is necessary.