* Re: [9front] Truetypefs anti-aliasing
@ 2025-01-20 10:08 qwx
2025-01-20 11:57 ` sirjofri
0 siblings, 1 reply; 15+ messages in thread
From: qwx @ 2025-01-20 10:08 UTC (permalink / raw)
To: 9front
> I posted this earlier on 9fans, but I should do it here:
> 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: image.png]
> I've attached the change, and 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.
> [image: image.png]
> Thoughts?
> Paul
I support this as well, though is there perhaps a different algorithm
to use for the filtering? It does look a bit blurry.
Thanks,
qwx
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 10:08 [9front] Truetypefs anti-aliasing qwx
@ 2025-01-20 11:57 ` sirjofri
2025-01-20 13:13 ` Steve Simon
2025-01-20 15:30 ` Sigrid Solveig Haflínudóttir
0 siblings, 2 replies; 15+ messages in thread
From: sirjofri @ 2025-01-20 11:57 UTC (permalink / raw)
To: 9front
20.01.2025 11:09:50 qwx@sciops.net:
>
> I support this as well, though is there perhaps a different algorithm
> to use for the filtering? It does look a bit blurry.
Maybe, with some kernel-like operation, it would be possible to not just "scale down" the image, but add subpixels instead? Like, if the neighboring pixels are X and Y, don't make it a mix of both, but red/blue/whatever?
Maybe, if I find time this week, I could try to adjust the code to do that (if you didn't do that already by then). I usually don't use truetypefs though, but I'm interested in subpixel rendering and fonts.
sirjofri
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 11:57 ` sirjofri
@ 2025-01-20 13:13 ` Steve Simon
2025-01-20 14:32 ` Paul Lalonde
2025-01-20 15:30 ` Sigrid Solveig Haflínudóttir
1 sibling, 1 reply; 15+ messages in thread
From: Steve Simon @ 2025-01-20 13:13 UTC (permalink / raw)
To: 9front
averaging neighbouring pixels is just poor people’s filtering. you would be better to use a well defined filter but one which trades off sharpness against jaggies in a way you like.
also beware that if any scaling of the picture is done downstream (e.g. the display is not run at native resolution) then this implies a second filter and your aliases will return - and the text will start to look really quite nasty.
-Steve
> On 20 Jan 2025, at 11:59 am, sirjofri <sirjofri+ml-9front@sirjofri.de> wrote:
>
> 20.01.2025 11:09:50 qwx@sciops.net:
>>
>> I support this as well, though is there perhaps a different algorithm
>> to use for the filtering? It does look a bit blurry.
>
> Maybe, with some kernel-like operation, it would be possible to not just "scale down" the image, but add subpixels instead? Like, if the neighboring pixels are X and Y, don't make it a mix of both, but red/blue/whatever?
>
> Maybe, if I find time this week, I could try to adjust the code to do that (if you didn't do that already by then). I usually don't use truetypefs though, but I'm interested in subpixel rendering and fonts.
>
> sirjofri
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 13:13 ` Steve Simon
@ 2025-01-20 14:32 ` Paul Lalonde
2025-01-31 16:39 ` qwx
0 siblings, 1 reply; 15+ messages in thread
From: Paul Lalonde @ 2025-01-20 14:32 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]
This is absolutely "poor people's filtering", though it is generating the
correct per-pixel coverage from the higher resolution 1-bit font.
A bilateral filter might do somewhat better for vertical and horizonal
edges, etc, though at higher cost.
Yet, this simple version makes truetype fonts *usable* where before they
have been *unusable*.
Regarding sub-pixel work, this requires any downstream user of the font to
know how to render those - you move from what's effectively a single alpha
mask for the font to an alpha mask per channel.
I believe these changes might be limited to memdraw, but I haven't done
enough analysis to be certain.
Paul
On Mon, Jan 20, 2025 at 5:41 AM Steve Simon <steve@quintile.net> wrote:
>
> averaging neighbouring pixels is just poor people’s filtering. you would
> be better to use a well defined filter but one which trades off sharpness
> against jaggies in a way you like.
>
> also beware that if any scaling of the picture is done downstream (e.g.
> the display is not run at native resolution) then this implies a second
> filter and your aliases will return - and the text will start to look
> really quite nasty.
>
> -Steve
>
> > On 20 Jan 2025, at 11:59 am, sirjofri <sirjofri+ml-9front@sirjofri.de>
> wrote:
> >
> > 20.01.2025 11:09:50 qwx@sciops.net:
> >>
> >> I support this as well, though is there perhaps a different algorithm
> >> to use for the filtering? It does look a bit blurry.
> >
> > Maybe, with some kernel-like operation, it would be possible to not just
> "scale down" the image, but add subpixels instead? Like, if the neighboring
> pixels are X and Y, don't make it a mix of both, but red/blue/whatever?
> >
> > Maybe, if I find time this week, I could try to adjust the code to do
> that (if you didn't do that already by then). I usually don't use
> truetypefs though, but I'm interested in subpixel rendering and fonts.
> >
> > sirjofri
>
[-- Attachment #2: Type: text/html, Size: 2551 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 11:57 ` sirjofri
2025-01-20 13:13 ` Steve Simon
@ 2025-01-20 15:30 ` Sigrid Solveig Haflínudóttir
2025-01-20 17:45 ` ori
1 sibling, 1 reply; 15+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2025-01-20 15:30 UTC (permalink / raw)
To: 9front
The more common way to do it, I believe, is to render 3x the size
(on either X or Y axis, depending on your display's pixels) image
of a character, then apply a FIR to get rid of as much color
banding as possible.
https://git.sr.ht/~ft/fnt does exactly that. The sources are there
for anyone to explore and contribute to.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 15:30 ` Sigrid Solveig Haflínudóttir
@ 2025-01-20 17:45 ` ori
2025-01-20 17:55 ` Sigrid Solveig Haflínudóttir
2025-01-20 18:06 ` Paul Lalonde
0 siblings, 2 replies; 15+ messages in thread
From: ori @ 2025-01-20 17:45 UTC (permalink / raw)
To: 9front
Quoth Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>:
> The more common way to do it, I believe, is to render 3x the size
> (on either X or Y axis, depending on your display's pixels) image
> of a character, then apply a FIR to get rid of as much color
> banding as possible.
>
> https://git.sr.ht/~ft/fnt does exactly that. The sources are there
> for anyone to explore and contribute to.
I the path forward may be to port truetypefs to this, and then
remove libttf -- Sigrid, thoughts?
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 17:45 ` ori
@ 2025-01-20 17:55 ` Sigrid Solveig Haflínudóttir
2025-01-20 18:06 ` Paul Lalonde
1 sibling, 0 replies; 15+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2025-01-20 17:55 UTC (permalink / raw)
To: 9front
> I the path forward may be to port truetypefs to this, and then
> remove libttf -- Sigrid, thoughts?
That's one way to do it, yeah. I am not exactly happy about truetypefs'
code itself so I am not sure if doing it from scratch is easier or not.
Somebody can try doing that - fnt already has a test tool that runs on
9front and can produce the whole glyph map as an image.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 17:45 ` ori
2025-01-20 17:55 ` Sigrid Solveig Haflínudóttir
@ 2025-01-20 18:06 ` Paul Lalonde
2025-01-20 19:01 ` Sigrid Solveig Haflínudóttir
2025-01-20 23:20 ` ori
1 sibling, 2 replies; 15+ messages in thread
From: Paul Lalonde @ 2025-01-20 18:06 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1908 bytes --]
libttf might still have a bit of life in it. I have another set of patches
that adds 8 bit support and am part way through changing the rasterization
to compute coverage analytically.
That removes the need for the truetypefs and ttfrender supersampling paths,
and makes it cheap to perform the coverage calculation at three different
offsets for subpixel coloring.
I think this is a more invasive change, requiring an API change to libttf,
adding a depth or format parameter to the allocation calls.
If we want to do subpixel then it's probably an even more invasive change,
using a full format specifier to allow libttf to generate r8g8b8a8 (r, g, b
for subpixel, raw coverage in alpha?), and then changes in devdraw and
drawterm support the correct compositing.
My opinion is that the short term "make truetype work" is to use my
truetypefs patch. The next step would be to move the coverage calculation
into libttf, in hscan(). The subpixel change is so invasive that I'd
prefer to wait (and perhaps help with) for the full do-over Sigrid is
working.
Are there any other users of truetypefs? It's now my daily driver for
rio/acme, with Kurinto and Go fonts in regular use. Though some the
Kurinto fonts have some problems in hinting which crash libttf.
Thoughts, Sigrid?
Paul
On Mon, Jan 20, 2025 at 9:53 AM <ori@eigenstate.org> wrote:
> Quoth Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>:
> > The more common way to do it, I believe, is to render 3x the size
> > (on either X or Y axis, depending on your display's pixels) image
> > of a character, then apply a FIR to get rid of as much color
> > banding as possible.
> >
> > https://git.sr.ht/~ft/fnt does exactly that. The sources are there
> > for anyone to explore and contribute to.
>
> I the path forward may be to port truetypefs to this, and then
> remove libttf -- Sigrid, thoughts?
>
[-- Attachment #2: Type: text/html, Size: 2517 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 18:06 ` Paul Lalonde
@ 2025-01-20 19:01 ` Sigrid Solveig Haflínudóttir
2025-01-20 23:20 ` ori
1 sibling, 0 replies; 15+ messages in thread
From: Sigrid Solveig Haflínudóttir @ 2025-01-20 19:01 UTC (permalink / raw)
To: 9front
Whichever path is fine with me until fnt is ready to replace whatever
is in 9front, though subpixel rendering there is really opt-in and
disabled by default - without a full overhaul of drawing logic in
9front it's not that much useful.
I personally for now settled with using ttfs¹ to convert² fonts I need,
until fnt is ready - I don't ever use truetypefs because it's full of
bugs, incomplete and does awful job at rendering.
¹ https://git.sr.ht/~ft/ttfs
² https://ftrv.se/21
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 18:06 ` Paul Lalonde
2025-01-20 19:01 ` Sigrid Solveig Haflínudóttir
@ 2025-01-20 23:20 ` ori
1 sibling, 0 replies; 15+ messages in thread
From: ori @ 2025-01-20 23:20 UTC (permalink / raw)
To: 9front
Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> libttf might still have a bit of life in it. I have another set of patches
> that adds 8 bit support and am part way through changing the rasterization
> to compute coverage analytically.
> That removes the need for the truetypefs and ttfrender supersampling paths,
> and makes it cheap to perform the coverage calculation at three different
> offsets for subpixel coloring.
> I think this is a more invasive change, requiring an API change to libttf,
> adding a depth or format parameter to the allocation calls.
I think that libttf isn't currently linked into anything other than truetypefs,
so it shouldn't be so hard to get away with with incompatible changes. It's up
to you whether you think it'd be better to put a bunch more effort into libttf
or to work with sigrid to get fnt in shape to replace it.
> If we want to do subpixel then it's probably an even more invasive change,
> using a full format specifier to allow libttf to generate r8g8b8a8 (r, g, b
> for subpixel, raw coverage in alpha?), and then changes in devdraw and
> drawterm support the correct compositing.
don't forget vncs.
> My opinion is that the short term "make truetype work" is to use my
> truetypefs patch. The next step would be to move the coverage calculation
> into libttf, in hscan(). The subpixel change is so invasive that I'd
> prefer to wait (and perhaps help with) for the full do-over Sigrid is
> working.
I'd be happy to commit this and libttf bugfixes. I can look over this patch
by next weekend, if nobody else gets to it first.
> Are there any other users of truetypefs? It's now my daily driver for
> rio/acme, with Kurinto and Go fonts in regular use. Though some the
> Kurinto fonts have some problems in hinting which crash libttf.
I use truetypefs, but mostly when giving presentations; it's the only option
for a font big enough for a slideshow.
> Thoughts, Sigrid?
>
> Paul
>
> On Mon, Jan 20, 2025 at 9:53 AM <ori@eigenstate.org> wrote:
>
> > Quoth Sigrid Solveig Haflínudóttir <sigrid@ftrv.se>:
> > > The more common way to do it, I believe, is to render 3x the size
> > > (on either X or Y axis, depending on your display's pixels) image
> > > of a character, then apply a FIR to get rid of as much color
> > > banding as possible.
> > >
> > > https://git.sr.ht/~ft/fnt does exactly that. The sources are there
> > > for anyone to explore and contribute to.
> >
> > I the path forward may be to port truetypefs to this, and then
> > remove libttf -- Sigrid, thoughts?
> >
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 14:32 ` Paul Lalonde
@ 2025-01-31 16:39 ` qwx
0 siblings, 0 replies; 15+ messages in thread
From: qwx @ 2025-01-31 16:39 UTC (permalink / raw)
To: 9front
On Mon Jan 20 15:33:43 +0100 2025, paul.a.lalonde@gmail.com wrote:
> This is absolutely "poor people's filtering", though it is generating the
> correct per-pixel coverage from the higher resolution 1-bit font.
> A bilateral filter might do somewhat better for vertical and horizonal
> edges, etc, though at higher cost.
> Yet, this simple version makes truetype fonts *usable* where before they
> have been *unusable*.
>
> Regarding sub-pixel work, this requires any downstream user of the font to
> know how to render those - you move from what's effectively a single alpha
> mask for the font to an alpha mask per channel.
> I believe these changes might be limited to memdraw, but I haven't done
> enough analysis to be certain.
>
> Paul
Hi,
These changes were reverted after review. The patch was committed a
bit hastily and without actual consensus in this discussion, nor
evidently reading and testing it first.
I'm sorry to say that it is too sloppy, with multiple inconsistencies
in style with regards to the rest of the code, also going against
common conventions as outlined in style(6).
In addition, in my opinion, it generally does not produce better
results. I tried several fonts and found the result to be
significantly worse. Your mileage may vary, but for me it just makes
everything blurry even at high font sizes. Some examples:
- Unifont 13.0.01: quite blurry at any font size, and performance with
CJK and others is even worse on older machines (sam(1) freezes for
several seconds on a thinkpad t61p); it makes CJK barely legible below
14-15.
- VGA-Medium: very blurry at any font size.
- Ubuntu regular: pratically unreadable below 12, and the bottom of
most letters is nearly invisible at anything below 20.
Without the patch, these fonts are all legible above 10. With it, the
reduced contrast from the blurriness makes letters difficult to make
out, and I struggle with it even at reasonable font sizes.
There are strong opinions on the topic of anti-aliasing and fonts.
Some like me prefer not to have it. However, in my opinion, the patch
degrades rendering quality in the general case in addition to the
style issues. Thank you for your work and for submitting this patch,
but unfortunately this is not acceptable. Sigrid is already working
on a better solution, replacing truetypefs altogether. In the mean
time, while it is a good idea to try to improve what we have, these
changes do not.
Again, thanks for attempting to fix truetypefs, but this
implementation needs improvement. Please also pay more attention to
style for future patches.
Cheers,
qwx
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 1:40 Paul Lalonde
2025-01-20 2:17 ` B. Atticus Grobe
2025-01-20 6:30 ` Blue-Maned_Hawk
@ 2025-01-30 5:32 ` ori
2 siblings, 0 replies; 15+ messages in thread
From: ori @ 2025-01-30 5:32 UTC (permalink / raw)
To: 9front
Quoth Paul Lalonde <paul.a.lalonde@gmail.com>:
> I posted this earlier on 9fans, but I should do it here:
> 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: image.png]
> I've attached the change, and 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.
> [image: image.png]
> Thoughts?
> Paul
>
Applied as a starting point, hoping we get improvements on the algorithm
soon.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 1:40 Paul Lalonde
2025-01-20 2:17 ` B. Atticus Grobe
@ 2025-01-20 6:30 ` Blue-Maned_Hawk
2025-01-30 5:32 ` ori
2 siblings, 0 replies; 15+ messages in thread
From: Blue-Maned_Hawk @ 2025-01-20 6:30 UTC (permalink / raw)
To: 9front
I can confidently say with complete confidence that i never want
anything that i use to ever have any amount of antiäliasing
whatsoëver. Antiäliasing only ever serves to make everything blurrier
and induce analog-like uncertainties into a digital world that should be
free of such horrors.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [9front] Truetypefs anti-aliasing
2025-01-20 1:40 Paul Lalonde
@ 2025-01-20 2:17 ` B. Atticus Grobe
2025-01-20 6:30 ` Blue-Maned_Hawk
2025-01-30 5:32 ` ori
2 siblings, 0 replies; 15+ messages in thread
From: B. Atticus Grobe @ 2025-01-20 2:17 UTC (permalink / raw)
To: 9front
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
On Sun Jan 19, 2025 at 7:40 PM CST, Paul Lalonde wrote:
> I posted this earlier on 9fans, but I should do it here:
> 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: image.png]
> I've attached the change, and 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.
> [image: image.png]
> Thoughts?
> Paul
Paul, Sigrid would like you to take a look at the font renderer she's been
working on at https://git.sr.ht/~ft/fnt . She's currently experiencing e-mail
issues and asked me to relay this. All mistakes in this message are my own.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* [9front] Truetypefs anti-aliasing
@ 2025-01-20 1:40 Paul Lalonde
2025-01-20 2:17 ` B. Atticus Grobe
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Paul Lalonde @ 2025-01-20 1:40 UTC (permalink / raw)
To: 9front
[-- Attachment #1.1.1: Type: text/plain, Size: 1266 bytes --]
I posted this earlier on 9fans, but I should do it here:
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: image.png]
I've attached the change, and 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.
[image: image.png]
Thoughts?
Paul
[-- Attachment #1.1.2: Type: text/html, Size: 1493 bytes --]
[-- Attachment #1.2: image.png --]
[-- Type: image/png, Size: 100138 bytes --]
[-- Attachment #1.3: image.png --]
[-- Type: image/png, Size: 29331 bytes --]
[-- Attachment #2: aatt.patch --]
[-- Type: application/octet-stream, Size: 4770 bytes --]
From: Paul Lalonde <plalonde@acm.org>
Date: Mon, 20 Jan 2025 01:29:09 +0000
Subject: [PATCH] Anti-alias/filter fonts from truetypefs
This makes TrueType fonts actually usable and attractive.
---
diff 6929781254e5c9ba711aec98bec81ebba947eabf 62441b383fa1274037427b4f7aea1d24a2ca0407
--- a/sys/man/4/truetypefs
+++ b/sys/man/4/truetypefs
@@ -29,6 +29,8 @@
is a
.IR font (6)
file generated for GNU Unifont at a size of 16.
+The generated fonts are supersampled to generate filtered 8 bit fonts instead of the
+1 bit fonts libttf generates.
.SH EXAMPLES
Use size 16 GNU Unifont for
@@ -48,3 +50,8 @@
.SH HISTORY
.I Truetypefs
first appeared in 9front (October, 2018).
+.SH BUGS
+The filtering generates blurry fonts for small point sizes.
+At small point sizes it is better to use a specialty bitmapped font.
+
+The filtering should happen natively in libttf, not in its dependents.
--- a/sys/src/cmd/truetypefs.c
+++ b/sys/src/cmd/truetypefs.c
@@ -126,10 +126,9 @@
}
static void
-blit(uchar *t, int x, int y, int tstride, uchar *s, int w, int h)
+blit8(uchar *t, int x, int y, int tstride, uchar *s, int w, int h)
{
int tx, ty, sx, sy;
- u16int b;
uchar *tp, *sp;
if(y < 0) y = 0;
@@ -137,26 +136,81 @@
sp = s;
for(sy = 0; sy < h; sy++, ty++){
tx = x;
- tp = t + ty * tstride + (tx >> 3);
- b = 0;
- for(sx = 0; sx < w; sx += 8){
- b |= *sp++ << 8 - (tx & 7);
- *tp++ |= b >> 8;
- b <<= 8;
+ tp = t + ty * tstride + (tx);
+ for(sx = 0; sx < w; sx ++){
+ *tp++ = *sp++;
}
- *tp |= b >> 8;
}
}
+// Allocate an 8bpp bitmap. We can remove this if we update libttf to support 8 bit bitmaps.
+static TTBitmap *
+newbitmap8(int w, int h, int depth)
+{
+ TTBitmap *b;
+ if(!(depth == 1 || depth == 8)) {
+ return nil;
+ }
+ b = mallocz(sizeof(TTBitmap), 1);
+ if(b == nil) return nil;
+ b->width = w;
+ b->height = h;
+ switch (depth) {
+ case 1:
+ b->stride = (w + 7) >> 3;
+ break;
+ case 8:
+ b->stride = w;
+ break;
+ }
+
+ b->bit = mallocz(b->stride * h, 1);
+ if(b->bit == nil){
+ free(b);
+ return nil;
+ }
+ return b;
+}
+
static void
+freebitmap8(TTBitmap *b) {
+ if(b == nil) return;
+ free(b->bit);
+ free(b);
+}
+
+
+TTBitmap *
+scaledown(TTBitmap *b)
+{
+ TTBitmap *a;
+ int i, j;
+ int scale;
+
+ scale = 8;
+ a = newbitmap8((b->width + 7)>>3 , (b->height +7)>>3, 8);
+ if(a == nil) sysfatal("ttfnewbitmap: %r");
+ for(j = 0; j < b->height; j++)
+ for(i = 0; i < b->width; i++){
+ if((b->bit[j * b->stride + (i>>3)] >> 7 - (i & 7) & 1) != 0)
+ a->bit[j/scale * a->stride + i/scale]++;
+ if(j % scale == scale - 1 && i % scale == scale - 1)
+ a->bit[j/scale * a->stride + i/scale] = ((a->bit[j/scale * a->stride + i/scale] * 255 + scale * scale / 2) / (scale * scale));
+ }
+ return a;
+}
+
+static void
compilesub(TFont *f, TSubfont *s)
{
int n, i, w, x, h, g, sz;
char *d, *p;
- TTGlyph **gs;
- TTFont *t;
+ TTGlyph **gs, *gts;
+ TTFont *t, *tscaled;
+ TTBitmap *scaleddown;
t = f->ttf;
+ tscaled = ttfscale(t, t->ppem * 8, 0);
n = s->end - s->start + 1;
gs = emalloc9p(sizeof(TTGlyph *) * n);
w = 0;
@@ -166,20 +220,22 @@
g = 0;
else
g = ttffindchar(t, s->start + i);
- if((gs[i] = ttfgetglyph(t, g, 1)) == nil && g != 0)
- gs[i] = ttfgetglyph(t, 0, 1);
+ if((gs[i] = ttfgetglyph(tscaled, g, 1)) == nil && g != 0)
+ gs[i] = ttfgetglyph(tscaled, 0, 1);
assert(gs[i] != nil);
- w += gs[i]->width;
+ w += (gs[i]->width + 7)>>3;
}
- sz = 5 * 12 + (w+7>>3) * h + 3 * 12 + (n + 1) * 6;
+ sz = 5 * 12 + w * h + 3 * 12 + (n + 1) * 6;
d = emalloc(sz);
- p = d + sprint(d, "%11s %11d %11d %11d %11d ", "k1", 0, 0, w, h);
+ p = d + sprint(d, "%11s %11d %11d %11d %11d ", "k8", 0, 0, w, h);
x = 0;
for(i = 0; i < n; i++){
- blit((uchar*)p, x, t->ascentpx - gs[i]->ymaxpx, w+7>>3, gs[i]->bit, gs[i]->width, gs[i]->height);
- x += gs[i]->width;
+ scaleddown = scaledown(gs[i]);
+ blit8((uchar*)p, x, t->ascentpx - ((gs[i]->ymaxpx+7)>>3), w, scaleddown->bit, scaleddown->width, scaleddown->height);
+ x += scaleddown->width;
+ freebitmap8(scaleddown);
}
- p += (w+7>>3) * h;
+ p += w * h;
p += sprint(p, "%11d %11d %11d ", n, h, t->ascentpx);
x = 0;
for(i = 0; i < n; i++){
@@ -187,12 +243,12 @@
*p++ = x >> 8;
*p++ = 0;
*p++ = h;
- *p++ = gs[i]->xminpx;
+ *p++ = (gs[i]->xminpx+7)>>3;
if(gs[i]->advanceWidthpx != 0)
- *p++ = gs[i]->advanceWidthpx;
+ *p++ = (gs[i]->advanceWidthpx + 7)>>3; // Already at the right scale from when we grabbed it from gts
else
- *p++ = gs[i]->width;
- x += gs[i]->width;
+ *p++ = (gs[i]->width+7)>>3;
+ x += (gs[i]->width+7)>>3;
}
*p++ = x;
*p = x >> 8;
@@ -200,7 +256,7 @@
s->ndata = sz;
for(i = 0; i < n; i++)
ttfputglyph(gs[i]);
- free(gs);
+ free(gs);
}
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2025-01-31 16:40 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-01-20 10:08 [9front] Truetypefs anti-aliasing qwx
2025-01-20 11:57 ` sirjofri
2025-01-20 13:13 ` Steve Simon
2025-01-20 14:32 ` Paul Lalonde
2025-01-31 16:39 ` qwx
2025-01-20 15:30 ` Sigrid Solveig Haflínudóttir
2025-01-20 17:45 ` ori
2025-01-20 17:55 ` Sigrid Solveig Haflínudóttir
2025-01-20 18:06 ` Paul Lalonde
2025-01-20 19:01 ` Sigrid Solveig Haflínudóttir
2025-01-20 23:20 ` ori
-- strict thread matches above, loose matches on Subject: below --
2025-01-20 1:40 Paul Lalonde
2025-01-20 2:17 ` B. Atticus Grobe
2025-01-20 6:30 ` Blue-Maned_Hawk
2025-01-30 5:32 ` ori
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).