On 2/25/25 15:03, Paul Lalonde wrote: > For anyone following along, my meagre efforts bounced off of 9front, so I've > gone and built something a bit nicer. https://github.com/paul-lalonde/ttffs > <https://github.com/paul-lalonde/ttffs> presents a derivative of truetypefs > that uses Sean Barett's stb_truetype.h rasterizer to generate 8 bit fonts > using correct coverage. This works well enough to run all the go fonts and > the kurinto fonts.
Just wanted to clarify from our angle, we had some discussion in irc regarding the patch and no one was fundamentally opposed to the work, it just felt like we hadn't had enough discussion on our end regarding the direction of what we wanted, and the patch seemed to have lots of little issues (style and formatting) that we decided it was best to back out for the time being. 9front works a bit loosely, we don't have strict approval rules for patches and contributors are given discretion for what gets merged. While this is nice, it does lead to things being reverted more often than you'd see in other projects as sometimes the discussion can only start to happen once someone takes the step to merge something. I just want to iterate that its not a condemnation of the work or the ideas presented in it, it's just how we operate. I've had many of my work get reverted over the years with 9front, especially things that tend to be more opinionated. The original author of truetypefs made an explicit decision to not do AA, so the main point of contention was whether or not the default should change. At the time there was thoughts that perhaps a flag for picking one or the other might be the best case for this scenario. I think we would still be interested in the work if it was behind a flag and the style had been more conformant with our style(6) manual page and that of the existing code. I think qwx mentioned a lot of this in a response email to the patch at the time we decided to revert the patch. It seems like you've decided to work on your own implementation and that's totally fine if you don't want to return to original truetypefs code. I just wanted to provide all of this context to not dissuade you from future work with the project and to give some context for how things work in 9front. Thank you, Jacob Moody > > The library also supports sub-pixel addressing, which will allow experiments > in adding sub-pixel rasterization, though that will require patches to > libframe and libdraw. > > This rasterizer does not implement hinting, so don't expect faithful > representations below about 16pt. This pains me not at all as I can't read > text any smaller than that anyway. > > There are minor differences in glyph spacing (though I may still have some > scaling mis-understandings/bugs) and scaling - I probably don't understand > the relationship between ppem and font native scaling correctly. > > I'll add that I have higher tolerance for blurriness than jagginess, > especially as I usually run on a non-scaled high-dpi display. > > Improvements and commentary welcomed. > > Comparisons of multiple resolutions below. > > Paul > > image.png > image.png > > image.png > > image.png > > On Sat, Jan 18, 2025 at 3:59 AM Steve Simon <st...@quintile.net > <mailto:st...@quintile.net>> wrote: > > > l would drop 1bit and put a warning in the manpage that results are not > so good at <10pt (sorry if thats obvious). > > low res displays are rare for desktop these days, and for embedded use i > would expect people to choose fonts explicitly for the display used > . > > -Steve > > > >> On 17 Jan 2025, at 9:27 pm, Ron Minnich <rminn...@p9f.org >> <mailto:rminn...@p9f.org>> wrote: >> >> >> I like the idea of ditching the 1 bit code path. >> >> I wonder, is the use of 1 bit historical, going back to days of 1 bit >> displays and small memory? Is there some reason it was ever used? >> >> thanks >> >> On Fri, Jan 17, 2025 at 12:16 PM Paul Lalonde <paul.a.lalo...@gmail.com >> <mailto:paul.a.lalo...@gmail.com>> wrote: >> >> I've made a modification to truetypefs to do what ttfrender does: >> render the font at higher resolution and filter down to a good looking 8 bit >> font. >> This is a significant improvement in the appearance of the fonts >> from truetypefs, as seen in the image below. Left is the one-bit font, >> right is the filtered font. >> image.png >> Before I send a PR, I have questions. >> I believe in being opinionated: the 8 bit version is so much better >> for every font I've compared that I don't see any use for the 1 bit versions >> anymore. >> How do other users feel about ditching the 1 bit code path and >> having only the 8 bit code path? This is the cleanest/smallest change. >> The alternatives would be to have a switch to truetypefs so that it >> always returns either 1 bit or 8 bit fonts; a switch in the fs setup to >> choose based on font size; a way to tell the fs what font depth to return >> (probably a hack like the font size now, very ugly). >> The cost of the filtering is low in compute for smaller point sizes, >> but starts to lag a bit at 30 point or so. It probably also blurs out very >> small sizes. I don't know that anyone chooses TrueType fonts for text under >> ~10pt however. Although the 10 pt below absolutely shows a minor problem >> with my font spacing that I'll need to fix. >> image.png >> Thoughts? >> Paul > > *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T965561871d922464-M96542c98d0309f77a466a035> ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T965561871d922464-M65fc3c3848c376b6dbecca66 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
