AmigaOS 3.2+ and Fonts

[Warty]

One of the things that has always bugged me about the Amiga from the very first days, was the general, well, sloppiness of the bitmapped fonts provided by Commodore, compared to what was available on the Mac.

Now that we're getting 3.2, and then another release after that (knock on wood), I have been thinking about what would make using the Amiga more fun, and so I started playing with FED to see if I could get some crisper fonts going.

Now, there are GREAT fixed width fonts for coding on Aminet. I won't spend any time there, as quite a lot of great fonts have already been converted, and a decent chunk of them have licenses that allow redistribution.

I'm thinking of a serif font, in various sizes, and a non-serif font in various sizes, both proportional. The goal is clarity, lack of fuzziness (extraneous pixels from poor rendering), consistent spacing, and general legibility. Side note: guess some people don't like XEN, but I think it's clear; the problem I see is more around redistribution: I'm pretty sure it is not allowed by the MUI license.

Questions:
- any interest in distributing a clearer set of fonts with WB 3.3 (figure too later for 3.2), if they had MIT or similar license? And maybe put some of the uglier fonts into a "other fonts" directory in case users want them?
- There is a section of character slots that were reserved for codes from $80-$9f. I think Windows reclaimed that section for -1252. We could cover some more characters, like Euro, Amiga left/right, more quote marks, more european characters if we could use those slots. Not sure what implications of that would be tho for system and existing software.
- Short of that, best place to stash the Euro? I see people putting it into $80 and also into the slot for that spiky-ball-thing.
- Does 3.2 still have the heinously wide Amiga A in menus for keyboard shortcuts? Any interest in adding an A (or hollow/filled 2 of them) char, and using that instead in 3.3?

Progress on first serif font
I started with the serif font. Inspired by times new roman, but also pixolde, some stitching patterns I found online, and New York (mostly the just the idea of having single line clarity at small sizes). Maybe needs one more smaller size as well. I can't imagine any one needs a larger one in this day and age.

BTW, glad FED got an unofficial update a while back. Some interesting challenges, but mostly just works.

Ruby from KS 1.x:


CGTimes: From KS 2.x?:


Times: From KS 2.x? - Better! but still not crystal clear


PixRomana - first pass.

[Matt_H]

What is this FED update you mentioned? I hadn't heard about it previously - I'd be interesting in taking a look.

I definitely agree that the character sets need to be extended to support more of the characters you mentioned. But as far as cosmetic improvements go, I think development resources would be better spent on system-level enhancements for ease-of-use of fonts:
1. Anti-aliasing support (probably with some sort of caching). This alone might make existing fonts prettier.
2. Extending bullet.library to support TTF/OTF. Or making bullet.library redundant by overhauling diskfont.library to support TTF/OTF directly (again, probably with some sort of bitmap caching if there's no way to get a decoding engine to render OTF as fast as bitmaps).
3. Better font family support in ASL, so we don't have Arial, Arial Bold, Arial Italic, Arial Bold Italic, etc. cluttering up our font requesters. Just one option for Arial and a cycle gadget to select the particular style.

At some point we'll need UTF-8 as well. Lots to do.

[Thomas Richter]

Originally Posted by Warty

One of the things that has always bugged me about the Amiga from the very first days, was the general, well, sloppiness of the bitmapped fonts provided by Commodore, compared to what was available on the Mac.

It is likely that at least the "courier" and "times" font you got with the 1.3 workbench were just rendered from the corresponding outline fonts and as such do not have ideal quality. I doubt they were hand-drawn.


Also note that the Amiga was not particularly successful in the semi-professional DP-market as the Mac was, so fonts are less important.



However, these fonts are standard, and programs may expect them to be present. As such, it is unlikely they are going to be replaced any time soon. If you have better or other fonts to propose, that is certainly great, but one cannot expect in general that programs pick them up. The best approach you can follow is to upload them to Aminet and hope that people use them.

Originally Posted by Warty

There is a section of character slots that were reserved for codes from $80-$9f.

These are not "reserved codes", this is just a set of control sequences defined by ISO, same as the control sequences reserved in the area from $00 to $1f$. Using them for glyphs is a bad choice because programs may instead execute control functions instead of rendering glyphs. For example, for the console.device all these codes have a special meaning and will not appear as rendered codes in the console output. This "space" therefore *MUST* remain reserved and any allocation for printable characters is in violation to the ISO/ANSI specs, and will also create a lot of confusion.

Originally Posted by Warty

I think Windows reclaimed that section for -1252.

Amiga follows the ISO 8859 Latin 1 character set and not some *snort* windows assignment.

Originally Posted by Warty

Short of that, best place to stash the Euro?

The best space is that defined by ISO-Latin-15, there replacing the glyph taken by the "generic currency symbol" in ISO-Latin-1. Note, however, that Amiga follows ISO-Latin-1 and not ISO-Latin-15, and at present, we do not have switchable code spaces (though this may come). So any appearance of the Euro symbol is, unfortunately, a violation of the specs.


What *would* be really needed would be switchable code spaces. Os 4 has them (to some degree), but it would be some work to make the Os aware of that. Likely not for 3.2.

Originally Posted by Warty

I see people putting it into $80 and also into the slot for that spiky-ball-thing.

0x80 is a control character, so it is an error to put it in there, and this "spiky ball thing" is the generic currency symbol I talked about, but replacing that violates ISO-Latin-1. You want a different encoding, namely ISO-Latin-15, but at present, we cannot switch encodings neither indicate encodings. That is certainly a shortcoming, but one that will take a while to overcome.

Originally Posted by Warty

- Does 3.2 still have the heinously wide Amiga A in menus for keyboard shortcuts?

Yes, but that is not a character of any particular font, but a boopsi of the vector class (IIRC) intuition provides, and thus does not appear in any codeset. It is scalable, but does not require localization as the key on your keyboard is also labelled the same, regardless of the font or nationality.

[Thomas Richter]

Originally Posted by Matt_H

What is this FED update you mentioned? I hadn't heard about it previously - I'd be interesting in taking a look.

FED is a pretty old font editor that shipped with 1.2 and 1.3. Astonishing that this beast still works.

Originally Posted by Matt_H

I definitely agree that the character sets need to be extended to support more of the characters you mentioned. But as far as cosmetic improvements go, I think development resources would be better spent on system-level enhancements for ease-of-use of fonts:
1. Anti-aliasing support (probably with some sort of caching). This alone might make existing fonts prettier.

This will not happen anytime soon. Graphics lacks any mechanism for that. It would require an indication of the subpixel arrangement to allow that, and pen allocation for the rendering. With the palette-lookup based video modes the amiga has, namely bitplanes with a limited set of colors, this makes even less sense. Which color should be picked for "grey" if you only have four colors available, namely the background grey, white, blue and black? Should graphics scan for each pixel the palette just to render a glyph?


Thanks, but this does not sound very plausible nor doable. Leave that to more powerful machines that are designed and used for professional layout, but not the Amiga.

Originally Posted by Matt_H

2. Extending bullet.library to support TTF/OTF. Or making bullet.library redundant by overhauling diskfont.library to support TTF/OTF directly (again, probably with some sort of bitmap caching if there's no way to get a decoding engine to render OTF as fast as bitmaps).

No, neither required nor necessary. Diskfont supports a nice "plugin" mechanism for font engines, and is such "agnostic" to the actual encoding. The "bullet.library" is just using this plugin mechanism to implement Compugraphic fonts (certainly a weird choice, probably only driven by finances, but not by technology).



However, nobody stops anyone from using this plugin mechanism for other encodings, such as PS or TTF. In fact, you can just go surfing in Aminet and find there the TTFFont manager and a similar engine for postscript fonts which can nicely coexist with each other. There is no need to extend the operating system in any particular way because all you need is possible, and in fact, already available as of today. Just use software that is there.

Originally Posted by Matt_H

3. Better font family support in ASL, so we don't have Arial, Arial Bold, Arial Italic, Arial Bold Italic, etc. cluttering up our font requesters. Just one option for Arial and a cycle gadget to select the particular style.

That is pretty much how ASL works. However, it didn't stop people from creating different font families with names that look "somehow related". ASL cannot tell whether "Arial" and "Arial Bold" are the same font if they appear as two different fonts in FONTS:.

Originally Posted by Matt_H

At some point we'll need UTF-8 as well. Lots to do.

Another thing that is unlikely to happen any time soon. UTF-8 uses a complicated multi-byte encoding, and graphics is retricted to a 256-glyph font. Actually, the whole font encoding is "single-byte-per-glyph" throughout the entire system, not just graphics, but intuition, and the console. It is very unrealistic anyone will rewrite all these parts anytime soon. The major dealbreaker is graphics here, depending on the "one-byte-per-glyph" design, and I wouldn't really know how to change that.



What is more realistic is a "switchable code base" version where you can select the encoding (such as switch between an ISO-Latin-1 encoding and an ISO-Latin-15 encoding), but even that requires some support throughout the system, from diskfont to ASL, and also CrossDos (yes, really). There is some code there in Os 4, though it is not entirely consistent.

[aros-sg]

Originally Posted by Thomas Richter

Thanks, but this does not sound very plausible nor doable. Leave that to more powerful machines that are designed and used for professional layout, but not the Amiga.

Of course one would use antialiased fonts only on hi or true color screens and AOS4, MorphOS, AROS support fonti anti aliasing since decades. Also home computers like Acorn Archimedes already supported it in the 1980s. Adding support for this to AOS 3.x would be very easy.

No, neither required nor necessary. Diskfont supports a nice "plugin" mechanism for font engines, and is such "agnostic" to the actual encoding. The "bullet.library" is just using this plugin mechanism to implement Compugraphic fonts (certainly a weird choice, probably only driven by finances, but not by technology).

Btw, with Aminet tool "Bitline" you can convert truetype and other outline fonts which you have installed on the system (with corresponding font engine) to standard Amiga bitmap fonts.

[Thomas Richter]

Originally Posted by aros-sg

Of course one would use antialiased fonts only on hi or true color screens and AOS4, MorphOS, AROS support fonti anti aliasing since decades. Also home computers like Acorn Archimedes already supported it in the 1980s. Adding support for this to AOS 3.x would be very easy.

But this isn't AOS4, Morphos or AROS, just plain old AmigaOs, and it is non-obvious to me how graphics can support them. Actually, it is not really graphics that renders fonts on RTG screens, but rather P96, and P96 uses the bit-expansion engine of the "blitter" that comes with some VGA chips. Which is, surprise, suprise, just binary.


Thus, I suppose if you think that this is easy, you come up with a proposal how to do that. All I can say from my perspective is that this isn't at all easy to integrate into the legacy architecture.

[aros-sg]

Originally Posted by Thomas Richter

Thus, I suppose if you think that this is easy, you come up with a proposal how to do that.

I know it's easy, because it's me who added antialias support for AROS ages ago. Basically you have diskfont->bullet stuff additionally query the font engine for anti aliased glyphs (~chunky gray buffer) and if so you turn the font into a FSF_COLORFONT with flag CT_ANTIALIAS with chunky gray (alpha) buffer in ctf_CharData (but you also keep the standard 1 plane font data in tf_CharData. In graphics/Text() check the flags and if you see it contains antialias data (chunky gray buffer) and rendering is into high or true color bitmap create the text template as chunky buffer and use new BltTemplateAlpha() instead of creating the text template as planar template and using old BltTemplate().


In AOS 3.x since high/truecolor rendering is anyway only done through external P96 you could either leave it completely to P96 to replace Text() and make P96 render AA fonts it AA data is there, or you add an empty do-nothing BltTemplateAlpha() or similiar function which P96 then replaces.



And/or clone however they did it in AOS4/AOS4-P96. Or whatever. It's of course also possible to implement BltTemplateAlpha() with unmodified or old P96/CGFX/whatever using ReadPixelArray() -> modify buffer -> WritePixelArray().


BltTemplateAlpha == BltTemplate, except the gray/alpha (instead of the binary 1/0) value indicates the degree by which to mix APen RGB with BPen RGB (JAM2) or APen RGB with background RGB (JAM1).

[Matt_H]

Thomas, thanks for these details.

Originally Posted by Thomas Richter

FED is a pretty old font editor that shipped with 1.2 and 1.3. Astonishing that this beast still works.

I know about the original FED... and how awful it is . But Warty mentioned an update that sounded interesting.

No, neither required nor necessary. Diskfont supports a nice "plugin" mechanism for font engines, and is such "agnostic" to the actual encoding. The "bullet.library" is just using this plugin mechanism to implement Compugraphic fonts (certainly a weird choice, probably only driven by finances, but not by technology).



However, nobody stops anyone from using this plugin mechanism for other encodings, such as PS or TTF. In fact, you can just go surfing in Aminet and find there the TTFFont manager and a similar engine for postscript fonts which can nicely coexist with each other. There is no need to extend the operating system in any particular way because all you need is possible, and in fact, already available as of today. Just use software that is there.

Yes, I've got the TTF and PS libraries installed on a few of my systems. The underlying issue I was speaking to here is that even those plugin systems are somewhat clunky. Fonts need to be installed with a tool (Intellifont, TTFManager, etc.) and require a lot of user intervention/configuration to get them working correctly in terms of render size (pixel vs. pt) and family recognition. They still need to have a corresponding .font file generated for them. At some future point it would be nice to be able to simply dump OTF fonts into Fonts:_otf and be done with it.

That is pretty much how ASL works. However, it didn't stop people from creating different font families with names that look "somehow related". ASL cannot tell whether "Arial" and "Arial Bold" are the same font if they appear as two different fonts in FONTS:.

Good to know. So this is more a configuration problem with TTFManager and the .font/.otag files than ASL? Although this does speak to the same sort of thing I mentioned above--it would be nice if the system could handle families transparently/automatically.

Another thing that is unlikely to happen any time soon. UTF-8 uses a complicated multi-byte encoding, and graphics is retricted to a 256-glyph font. Actually, the whole font encoding is "single-byte-per-glyph" throughout the entire system, not just graphics, but intuition, and the console. It is very unrealistic anyone will rewrite all these parts anytime soon. The major dealbreaker is graphics here, depending on the "one-byte-per-glyph" design, and I wouldn't really know how to change that.

Interesting challenge. Possible starting point: have you looked at Commodore's work on implementing Japanese support? From what I can tell it used some clever addressing/remapping trickery and multi-file fonts to be able to store and display the Japanese character set, which I suspect is far more than 256 glyphs. Maybe something similar could be done for UTF.

What is more realistic is a "switchable code base" version where you can select the encoding (such as switch between an ISO-Latin-1 encoding and an ISO-Latin-15 encoding), but even that requires some support throughout the system, from diskfont to ASL, and also CrossDos (yes, really). There is some code there in Os 4, though it is not entirely consistent.

Or maybe this was how Commodore did Japanese? I'm not sure. I think 2.04 did something like this with bullet.library. There was an option somewhere to select which particular character set would be accessible through the .font/.otag file, but it was very clunky to access and couldn't be changed once the font was installed. I don't think it carried over into 2.1+. Still, maybe it's something to build from?

[Thomas Richter]

Originally Posted by aros-sg

I know it's easy, because it's me who added antialias support for AROS ages ago. Basically you have diskfont->bullet stuff additionally query the font engine for anti aliased glyphs (~chunky gray buffer) and if so you turn the font into a FSF_COLORFONT with flag CT_ANTIALIAS with chunky gray (alpha) buffer in ctf_CharData (but you also keep the standard 1 plane font data in tf_CharData.

Color fonts are not the same as antialiased fonts. Anti-aliasing requires some sort of sub-pixel rendering, and there is no source where the sub-pixel arrangement can be be taken from, so this needs to be invented. Even then, someone need to touch bullet.library, and that is legacy Agfa code that works mostly due to layers of duct tape and chewing gum. So it would need at least some rendering engine where subpixel-rendering and anti-aliasing is part of the concept, as bullet does not have it.


Compugraphic is actually the wrong engine for this type of fun anyhow, it is more for high-resolution professional printing than low-dpi screen rendering without hinting, but well, this was CBM. It was probably cheap to get.


Hence, I doubt anyone will touch this in the near future, at least I won't.

[Thomas Richter]

Originally Posted by Matt_H

I know about the original FED... and how awful it is . But Warty mentioned an update that sounded interesting.

I afraid I don't have that, but there were a couple of more professional choices available for the Amiga which I forgot and I wouldn't have either.

Originally Posted by Matt_H

Yes, I've got the TTF and PS libraries installed on a few of my systems. The underlying issue I was speaking to here is that even those plugin systems are somewhat clunky. Fonts need to be installed with a tool (Intellifont, TTFManager, etc.) and require a lot of user intervention/configuration to get them working correctly in terms of render size (pixel vs. pt) and family recognition. They still need to have a corresponding .font file generated for them. At some future point it would be nice to be able to simply dump OTF fonts into Fonts:_otf and be done with it.

That would require a bit more system support for it, and at least that is not easy. I remember I once tried to add Fonts to my Linux system and it was a medium nightmare to get that working, even with the help of some opaque tool whose name just escaped me. Unfortunately, pretty much every font engine has some machinery of its own - how it structures its fonts, how it orders its families, so I wouldn't know whether something generic is plausible.


Fontain aka Intellifont got better, but in its core, it is still agfa code of rather moderate quality.

Originally Posted by Matt_H

Good to know. So this is more a configuration problem with TTFManager and the .font/.otag files than ASL? Although this does speak to the same sort of thing I mentioned above--it would be nice if the system could handle families transparently/automatically.

I afraid it is more a conceptual problem than really an ASL or TTFManager problem. The way how TTF manager maps various styles is through different fonts, but there is neither a good concept at system level to provide fonts of different styles and group them in families. diskfont does not have a good concept for that, and graphics neither. graphics can make a font "bold", but its "bolding" algorithm is something a lot more primitive than an alternative "cut" (is this the right english term?) of the same source font TTF can provide.


Again, it is not just a matter of "a couple of tweaks here or there", it is more a matter of entire concepts simply being forgotten, or not considered. Mix that with the overall weak design of graphics, and you see the reason for my reluctance.

Originally Posted by Matt_H

Interesting challenge. Possible starting point: have you looked at Commodore's work on implementing Japanese support? From what I can tell it used some clever addressing/remapping trickery and multi-file fonts to be able to store and display the Japanese character set, which I suspect is far more than 256 glyphs. Maybe something similar could be done for UTF.

No, I haven't, and I doubt I'll have that. I have no idea how this works.

Originally Posted by Matt_H

Or maybe this was how Commodore did Japanese? I'm not sure. I think 2.04 did something like this with bullet.library. There was an option somewhere to select which particular character set would be accessible through the .font/.otag file, but it was very clunky to access and couldn't be changed once the font was installed. I don't think it carried over into 2.1+. Still, maybe it's something to build from?

Well, Compugraphic fonts surely can contain a lot more than 256 characters. They use their own encoding, agfa style, not compatible to anything, not UTF of any form. If I recall correctly, the mysteriously named "if.uc" file is nothing but a list how to map the agfa encoding to the target Os encoding, essentially giving for each target glyph location (ISO-Latin-1 in our case) a list (so multiple, really!) source positions in the agfa encoding where to look for matching glyphs.


So, for example, agfa has multiple encodings for ', and characters that look alike, such as ´, and then uses a search for best matching glyph in the font to satisfy the request for a particular glyph in the target encoding.



I remember because one of the team mates helped drilling up "if.uc" to get some fonts working that used somewhat unconventional glyph positions for certain ISO characters.


Anyhow, the story is that whenever you use an agfa font, bullet has to map it to a 256 alphabet because this is all graphics is capable of (through "if.uc", as said), so you cannot render more than 256 glyphs of a font at once. If you need more, alternative glyphs, you need to create a new font with a new mapping.


Thus, this is not really workable. You would need to make graphics aware of larger fonts, then make console aware of larger fonts, then make console aware of multi-font encoding, and would still have the problem that there is certainly more than one program around that "measures" the size of a non-proprotional text by multiplying the number of characters with the X-Size of the font.


Thus, a lot of the "abstractions" graphics makes are inappropriate. Font dimension and string length are no longer related, to name one.


With code books, one could at least provide one "if.uc" file per code book and thus can render the same agfa font to multiple bitmap fonts with different encodings. But for utf-8, the problem is a lot larger.



Long story short: It's always the same problem: Lack of proper abstraction at all system layers, in particular in graphics.

[Warty]

Originally Posted by Matt_H

What is this FED update you mentioned? I hadn't heard about it previously - I'd be interesting in taking a look.

It may not be an entirely official update. Google "Font Editor for AmigaOS 2.x/3.x" and it will be the first hit.

It does have a few quirks, but it gets the job done.

[Warty]

Originally Posted by Thomas Richter

It is likely that at least the "courier" and "times" font you got with the 1.3 workbench were just rendered from the corresponding outline fonts and as such do not have ideal quality. I doubt they were hand-drawn.

I think that's a safe bet. OTOH, Garnet, Ruby, etc, were definitely hand drawn. (in about 5 minutes flat, I suspect).

Originally Posted by Thomas Richter

Also note that the Amiga was not particularly successful in the semi-professional DP-market as the Mac was, so fonts are less important.

From a DTP perspective, certainly fonts have almost no importance now, because this is a hobby machine, and no one does professional DTP work with it. But, as a hobby machine, I think most people like to work with clear, easy-to-ready fonts (compared to muddy, sometimes ugly ones).

Originally Posted by Thomas Richter

However, these fonts are standard, and programs may expect them to be present. As such, it is unlikely they are going to be replaced any time soon. If you have better or other fonts to propose, that is certainly great, but one cannot expect in general that programs pick them up. The best approach you can follow is to upload them to Aminet and hope that people use them.

I'm not sure what programs that are in any kind of use today would be expecting Times or something to be present, and then not perform right if absent, but setting that aside... how about another option: we replace the existing bitmaps with cleaner ones, for a few select fonts. They would need to have the same point sizes (adding more shouldn't be a problem though). The could perhaps also have hand-drawn italic/bold/bolditalic versions? If Commodore actually licensed times and helvetica, those would be good candidates for hand-drawn replacements. I couldn't personally bear to spend time on Courier when there are so many other clear-license alternatives. A good proportional bold font for the system / menus would be good though. Leaving Topaz in ROM of course, would it be so bad to select a new default system font, so that the OS looks a bit better right out of the box? There are tons of great totally open source fonts that we could convert to clean Amiga versions for the required sizes. (some already are converted on Aminet, but lots of stuff on Aminet is not licensed for redistribution).

Originally Posted by Thomas Richter

Using them for glyphs is a bad choice because programs may instead execute control functions instead of rendering glyphs. For example, for the console.device all these codes have a special meaning and will not appear as rendered codes in the console output. This "space" therefore *MUST* remain reserved and any allocation for printable characters is in violation to the ISO/ANSI specs, and will also create a lot of confusion.

Amiga follows the ISO 8859 Latin 1 character set and not some *snort* windows assignment.

Pretty sure Amiga was designed with ECMA-94 (1984) and not 8859-1 (1987?) (http://www.ecma-international.org/pu...rch%201985.pdf), but point taken...

Originally Posted by Thomas Richter

The best space is that defined by ISO-Latin-15, there replacing the glyph taken by the "generic currency symbol" in ISO-Latin-1. Note, however, that Amiga follows ISO-Latin-1 and not ISO-Latin-15, and at present, we do not have switchable code spaces (though this may come). So any appearance of the Euro symbol is, unfortunately, a violation of the specs.

What *would* be really needed would be switchable code spaces. Os 4 has them (to some degree), but it would be some work to make the Os aware of that. Likely not for 3.2.

I agree that seems like a more sustainable/better way to go.

[Matt_H]

Originally Posted by Warty

It may not be an entirely official update. Google "Font Editor for AmigaOS 2.x/3.x" and it will be the first hit.

It does have a few quirks, but it gets the job done.

Thanks. Is this the one? http://bax.comlab.uni-rostock.de/en/projects/fonted/

There’s TypeSmith for serious font work, but sometimes you want a simple tool for a simpler task.

[aros-sg]

Originally Posted by Thomas Richter

Color fonts are not the same as antialiased fonts.

Colorfont flag/style CT_ANTIALIAS exists in original/old AOS headers. So it was (mis?)used to indicate that font has antialiasing data in addition to old style monochrome planar font/glyph pixels. Antialiased fonts are in certain way some kind of color font, because they do not just contain "black" and "white" but also all the "greys" inbetween.

Anti-aliasing requires some sort of sub-pixel rendering, and there is no source where the sub-pixel arrangement can be be taken from, so this needs to be invented.

Standard font antialiasing on any OS does not work with sub pixel rendering. It's really just alpha blending between APen RGB and BPen RGB (JAM2) or APen RGB with background RGB (JAM1). The per pixel alpha value for this comes from the 8 bpp chunky buffer the font engine generate. The truetype font engines (bullet API) on Amiga use freetype like many other OSes and freetype generates this chunky buffer == alpha buffer == greymap buffer for glyphs for you so all that work is done by existing code and you don't have to care about it.

[Krashan]

Originally Posted by Thomas Richter

Anti-aliasing requires some sort of sub-pixel rendering

No. Subpixel rendering may be used to improve antialiasing, but is not a requirement. Moreover, subpixel rendering only makes things worse, when logical pixels are not identical to physical LCD pixels. This is usual case for Amigas, as available RTG solutions do not keep up with modern displays, so image is often upscaled. For example my TTEngine project provided antialiased TrueType display for AmigaOS 3.x with RTG, (based on FreeType library) while it did not use subpixel rendering.

[Thomas Richter]

Thanks, I understand. Please note, though, that TTF is not part of the operating system, but bullet is, and the bullet library has no idea about anti-aliasing. Neither has grapihcs (or P96, or the hardware it runs on) an idea about alpha-blending, so it would require a CPU-only implementation, which means at least one multiplication per pixel. Now combine that with the target platform, which is a 68000 running at 7Mhz, and you'll probably see why I don't consider this realistic.

[Bruce Abbott]

Originally Posted by Warty

how about another option: we replace the existing bitmaps with cleaner ones, for a few select fonts. They would need to have the same point sizes (adding more shouldn't be a problem though).

Yes, this a great idea. But they don't need to be supplied with the OS.

Leaving Topaz in ROM of course, would it be so bad to select a new default system font, so that the OS looks a bit better right out of the box?

The default system font should be Topaz because it is in ROM (and many programs assume it will be the default). But you can make your default font whatever you want, so why should the OS have to select one? Do you expect the typical OS3.2 user will be so ignorant that they won't know how to use preferences?

Originally Posted by Krashan

Subpixel rendering may be used to improve antialiasing, but is not a requirement. Moreover, subpixel rendering only makes things worse, when logical pixels are not identical to physical LCD pixels.

Many of us older people don't need antialiasing because our eyes already do it. The last time I 'upgraded' Firefox on my PC the text went all blurry. I managed to make it a bit better by changing some undocumented settings, but it still antialiases and makes small text less sharp than it used to be. I hate PC's!

My A1200 displays in composite on my big TV, so flicker fixing and 'antialiasing' is built in. It works great provided I don't wear glasses and let my eyes blur the text slightly. I also discovered that my small TV has a '1:1' scaling option, which works great with the Vampire. My system font on the Vampire is set to Thin711 for a nice clean look that makes every pixel count. Just the way a retro font system should be!

[bubbob42]

Originally Posted by Thomas Richter

Now combine that with the target platform, which is a 68000 running at 7Mhz, and you'll probably see why I don't consider this realistic.

This was - and still is - the *minimum* target plattform.

[coldacid]

bubbob42: That just means that bells-and-whistles features don't need to target it, but anything basic (like built-in graphics and font rendering) has to.

While fonts could certainly use an overhaul for Amiga, it's not something that should be out of box with the OS so long as the target platform remains as it is.

[Krashan]

Originally Posted by Thomas Richter

Now combine that with the target platform, which is a 68000 running at 7Mhz, and you'll probably see why I don't consider this realistic.

I agree, also antialiasing only makes sense on direct pixel-color screens, which excludes all the Amiga chipsets and 8-bit screens on RTG.