Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The FAQ is unclear about potential rounding of coordinates in PostScript #54

Open
elmimmo opened this issue May 4, 2015 · 3 comments
Open
Assignees

Comments

@elmimmo
Copy link

elmimmo commented May 4, 2015

The FAQ, in the question Is it safe to use non-integral coordinates? states that:

PostScript (type1, PostScript OpenType, type2, etc.) fonts can express non-integral coordinates in the font format–but it takes a lot more space in the font file. Type1 fonts tend to take more space to express this than type2 (opentype) fonts. By default FontForge will round to int on these as well, BUT you can change that in the Generate Options dialog.

but then afterwards, in the question How does FontForge convert a quadratic spline into a cubic (when reading truetype)? it notes that:

[When converting from quadratic to cubic splines] probably the control points will no longer be at integral coordinates and there will be some loss of precision when they are saved in a cubic format.

I guess the FAQ means that the above will happen "when they are saved in a cubic format with default settings in the Generate Options dialog" which, according to the answer to the other question, have “round to int” irrespective of the output format.

I take it then that setting “round to int” to off would indeed allow generating PostScript outlines from a Truetype input without any precision loss whatsoever, right?

@ghost
Copy link

ghost commented May 4, 2015

Even with round to int turned off, I think there is some limit to the amount of precision stored in the font file (perhaps six or eight digits after the decimal point) and that's the main way in which some precision may be lost.

Beyond file format issues, there is a finite limit to how precise FontForge's internal representation of numbers can be at all (typically double-precision IEEE floating point, equivalent to about 16 decimal digits) and you can only maintain at most that much precision through any cubic/quadratic conversion.

It's unlikely that these issues would really be a problem for anybody, but "I loaded and saved a file and the result wasn't bit-for-bit identical" is a common complaint and this FAQ answer is trying to answer that kind of concern.

@elmimmo
Copy link
Author

elmimmo commented May 5, 2015

Thanks for clearing that up.

@elmimmo elmimmo closed this as completed May 5, 2015
@davelab6 davelab6 self-assigned this May 5, 2015
@davelab6 davelab6 reopened this May 5, 2015
@davelab6
Copy link
Member

davelab6 commented May 5, 2015

I'll keep this open until the FAQ is updated :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants