I made a font that consists only of (many) circles, when printed as CCF-OTF, about half of the circles change their shape from 4-node-circles to 5-node-shapes, with starting-points doubled and shifted, about 2 units horizontally and vertically. Beside this, the whole thing is slanted to the left. This happens, when I print from InDesign, but not, when printing from TextEdit. No matter if exported with or without subroutines.
When I open the exported .otf-file with glyphs, everything looks good, when I open it with fontlab the same effect appears: many 4-node-circles change to 5-node-shapes, this time everything slanted to the right. It seems to happen only to circles with decimal-coordinate-BCPs x.5, but not to circles with decimal-coordinate-nodes x.25/x.75. In addition, all decimal values are rounded to whole numbers. When opening the .otf-file with Glyphs, the decimal-coordinates appear as in the original Glyphs-file.
According to the Glyphs-manual decimal-coordinates shouldn’t be a problem: »Contrary to popular belief, decimal coordinates can be exported into PS-based OTFs.«. So where does the problem occur??
That can happen when you have fractional coordinates. What is you grid setting? I didn’t see those issues for some time. You need to Round Coordinates from the Paths menu.
Subdivision was 4. I changed it to 3 and it works with x.333 and x.667, later changed to 5 and got slightly »rounder« values x.2; x.4; x.6 and x.8
The actual size of the subdivision doesn’t matter. The fact that you have fractional coordinates the causing the problem.
It seems to matter, cause the Fit Curve-tool aligns the BCPs according to the subdivision. The nodes itself were all on full coordinates.
Any node (off or oncurve) with fractional coordinates will trigger this?
I tested several offcurve nodes (x.0; x.5; x.25; x.75; x.333; x.667; x.2; x.4; x.6 and x.8) and it happens only at circles with BCPs x.5-coordinates.
By the way: changing cubic to quadratic-paths also can result in different values, e.g. minus ∆X11.5 becomes (minus) ∆X8,5, but plus 11.5 becomes (plus) ∆X8.75. So probably there could be a general problem with .5-coordinates.
How did you get to that output? Certain printer drivers and Quark XPress are incompatible with decimal coordinates.
A colleague type designer reported the bug to Quark. The front desk person replied that it’s too small a deviation to be significant. I didn’t follow up on it because XPress is already too insignificant IMO.
I printed it with InDesign CC2020. Just tested with Quark 7.5 and got the same result. TextEdit, Word and OpenOffice prints correctly.
It’s quite strange that professional DTP-software can’t do what word processors can.
It is most likely a (at least partially) a problem with your printer driver. When you print from Indesign or Quark, it is most likely operated in a different mode (PostScript? the printer sees the font data) as when printing from the other apps (the printer get outlines or even pre-rendered pixel data).
It’s a Kyocera Postscript-Printer. Many years ago, when I used Quark I got regular Postscript-errors when printing tiff-images.
Another problem: glyphs with more then ca. 97 circles (> 1164 on- and offcurve-nodes) are not printed, no matter witch app is used. As far as I know, each circle is broken down into many, many straight lines and this causes a kind of overflow. TrueType-fonts are not affected by this.
Is this with our without subroutines?
And do you happen to have another printer somewhere?
No matter if with or without subroutines. If I convert the text to paths It will be printed. I only have this printer.