-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
[rtext] Font size is being treated as an integer, but stb truetype accepts float size #3766
Comments
This is a breaking change and I'm considering it carefully. Also, it seems a bit weird that a font size should be requested with decimal values, it makes me think something is not properly considered on raylib internal font rasterizer... raylib uses |
@raysan5 PS: I just opened a blank document in Microsoft Word and see that the default Calibri font has a 10.5 pt setting. I know I have seen other fractional font sizes around the small end, usually with a .5 fraction. So there are at least TrueType fonts that can be rendered fractionally. |
@orcmid That means it has literally nothing to do with postscript. Postscript is solely a format to pack data that also allows to give relative size of a sheet so it can be properly reproduced. In other words it supports printing systems, not screen systems. |
I don't think that's completely accurate with regard to imaging with PostScript, Interpress, TeX, or other final-form imaging/printing systems. Those systems have to deal with font rendering via digital graphics, whether screens or laser printers. There are cross-overs between imaging on screens and on paper, although I do agree that the nomenclatures get murky. My impression with raylib is that there is a confusion between pixels (and some presumed dpi) and other typographical measures with regard to text. And thank you for the elaborate account. |
well if we'd take it not so narrow than pdf is successor to postscript. "PostScript is a page description language developed by Adobe Systems in the 1980s. It describes the appearance of a printed page in a device-independent manner. PostScript files contain instructions that describe how to draw text, graphics, and images on a page, and they can be interpreted by a PostScript-compatible printer or by software that interprets PostScript code." and the logic follow up on those widely accepted standards became PDF. The whole trick on modern font interpretation is about keeping font data as original as much as possible until the last step of rasterisation is inevitable. Which is the case with opengl/raylib of course. |
@designerfuzzi I don't want to continue this conversation since it is now far afield from the subject of this discussion. I do want to correct some historical difficulties with the material you are quoting. I do agree with the statement
I would like to point out that PDF started out as a customization of PostScript to be page-oriented, which PostScript did not require. Also, PostScript was used in a sort-of-native way on the original Macintosh. It is not appropriate to think of one as a subset or successor of the other. The prominence of PDF as a mostly-final-form document-interchange format is well-earned of course. I also worked on a project where Adobe provided a preprocessor board for Windows PCs that would emit Interpress from Postscript files. This was to allow a document processing flow from Windows through a Windows-based server that acted as a front-end to DocuTech, which used XNS protocols and ripped Interpress. That work was done prior to announcement of DocuTech. I don't know if it ever shipped. I worked on a similar project that used a form of ODA and shipped images through a customized Unix server to DocuTechs. This was used in a book preservation project at Cornell University, and the resulting scanned documents are available online from there. They could also be printed and bound on-demand via a DocuTech installed there. There are no font issues here, and the differences between write-white and write-black xerographic printing not a particular issue at 1200 spi :). More than that, I recall when all of those document-publishing forms were introduced and I knew some of the people involved. That's an interesting use of "rip." I'd forgotten about that. I use PDF/A wherever I can :). My contemporary Donald Knuth's experience with the creation of TeX and the creation and handling of fonts provides a great public account as he strove to provide publication quality laser-printed photo-lithography masters that would be used to provide beautiful mathematical texts and notations in his series of books and those of others. There is great attention on font scalability including adjustments to how our eyes deal differently with fonts on different sizes, requiring anamorphic thickening toward the small end. |
Issue description
Font size in raylib is passed along the api as an int, but truetype accepts a float value. The reason why this is important is because the sharpness of a font rasterized by stb truetype is highly dependent on this value, with steps as small as 0.05f making a noticeable difference. By using integer font sizes, only some fonts (especially affecting pixel fonts) are able to align properly to the rasterization grid. If we use a float value instead, we are able to fine tune the size necessary per font to reach perfect rasterization.
To enable this to work, a few functions and a struct need to be altered to change the type from int to float.
This is a big api change, but the results should be a great benefit.
Issue Screenshot
Here we can see a font rasterized at 13pt, with a severe subpixel halo:
Not good at 12pt either:
But 12.7pt works perfectly!
Code Changes
The text was updated successfully, but these errors were encountered: