New GUI for the Atari 8-bit

[fibrewire]

After watching this new video many times over the last couple of weeks, the small font now seems normal and extremely legible. The Icon font seems a good normal size, but now the menu and title bar font feels disproportionately large. Am I the only person experiencing this post-2013 dementia?

 

I can't WAIT until I can hold this cart up to the light like one would do with a fine gemstone!

[flashjazzcat]

After watching this new video many times over the last couple of weeks, the small font now seems normal and extremely legible. The Icon font seems a good normal size, but now the menu and title bar font feels disproportionately large. Am I the only person experiencing this post-2013 dementia?

I'm also a big fan of the small font in the latest demo, and while everyone's tastes are different, it might be a good idea to make the system font user-selectable. Now, who knows whether it's possible to make a good-looking Chicago-esque font at a reduced point size, but there'll be plenty of attractive small fonts to choose from.

 

I can't WAIT until I can hold this cart up to the light like one would do with a fine gemstone!

By the time it's finished, there should have been plenty of opportunity for precious stone formation.

[fibrewire]

I'm also a big fan of the small font in the latest demo, and while everyone's tastes are different, it might be a good idea to make the system font user-selectable. Now, who knows whether it's possible to make a good-looking Chicago-esque font at a reduced point size, but there'll be plenty of attractive small fonts to choose from.

 

I did not mean any offence, the font looks great! i was just sharing an observation that with screen real estate at a premium, the system font looks large compared to the icon and small font. But like you said, the task really comes down to the possibility of a reduced point system font size.

 

Keep up the awesome work!

[flashjazzcat]

 

I did not mean any offence, the font looks great!

 

Did I seem offended in any way? I hope not. Anyway: I'm sure MrFish appreciates the feedback on the fonts, which are indeed great.

[+MrFish]

After watching this new video many times over the last couple of weeks, the small font now seems normal and extremely legible. The Icon font seems a good normal size, but now the menu and title bar font feels disproportionately large.

 

Yes, actually I was thinking the same thing about the menu bar font. Of course it has to be realized that it's not only larger but also bold. Replacing the menu font with a regular font rather than bold would be one way to relieve that feeling. In some of the early builds of the GUI, as can be seen by looking back in this thread, Jon was using a regular font at times, as well as a smaller bold font (out of necessity at the time).

 

He also did a few tests back in 2011 (pictured in the screenshots below) to see what some smaller fonts would look like in the menus. I'm not sure exactly what font the first shot is of, but the second one is the icon label font:

[One note on the screentshots, is that Jon just hacked them in at the time. So underlining is stuck against the bottom of the characters and some spacing proportions don't look right. Obviously those would be taken care of in the GUI proper.]

 

 

 

I'm pretty sure I have some shots, and even XEX's of some others fonts in action too, but I'd have to take some time to look for them. Maybe Jon can demo up a few of the other fonts to let people have a look at them.

 

 

I'm also a big fan of the small font in the latest demo, and while everyone's tastes are different, it might be a good idea to make the system font user-selectable. Now, who knows whether it's possible to make a good-looking Chicago-esque font at a reduced point size, but there'll be plenty of attractive small fonts to choose from.

 

I'm sure a bold system menu font could be done in a couple smaller sizes as well. As I've mentioned before, I'm all for making all system fonts as configurable as possible, and I'd be down for creating as many fonts as needed to enable users to get the look, feel, and usability they prefer.

Edited January 7, 2014 by MrFish

[fibrewire]

I'm sure a bold system menu font could be done in a couple smaller sizes as well. As I've mentioned before, I'm all for making all system fonts as configurable as possible, and I'd be down for creating as many fonts as needed to enable users to get the look, feel, and usability they prefer.

 

After seeing those older screenshots I have a newfound appreciation for the decision making process in regards to software interface aesthetics. However I would still like to see that icon font in bold for a side-by-side system font comparison.

[flashjazzcat]

Yes: my first reaction was that the existing system font is damned near perfect. However, I'll put some comparisons together in a bit. One immediate effect of a small system font is that those 320x200 pixels look comparatively larger, making the interace slightly less nicely balanced. Another reason we use a bold system font is that it looks good greyed out: lighter fonts don't. A smaller system font which is still boldface might look pretty good. As I say: I'll have a play. Might be a useful opportunity to ensure the UI scales correctly.

[+MrFish]

Another reason we use a bold system font is that it looks good greyed out: lighter fonts don't.

 

Yes, we don't have the luxury of actually making the font's color grey when needed, as Windows does. We did banter about a few ideas for alternate ways of making non-bold system fonts grey out a little better. Although I know as a programmer you look for the "one method fits-all" approach, as anyone would.

 

[fibrewire]

 

Yes, we don't have the luxury of actually making the font's color grey when needed, as Windows does.

 

Well, if the smaller font doesn't work when greyed out then PLEASE disregard all of my posts from the last couple of days. Like FJC mentioned, the current system font is damned near perfect. It was just a reflexive reaction from seeing that new tiny font rendered so flawlessly

[flashjazzcat]

The way Windows does greying is irrelevant to us, since the mono precedents are GEM and Mac OS, both of which implement greying the way I've done it here. Far from being a coding consideration (since it was easy to try stuff like horizontal strike-thru, and I did, and wasn't impressed with the result with light and bold fonts alike), the decision to use the standard dithering method was an aesthetic one. I've never balked at writing extra code to make things look good (being not entirely oblivious to aesthetics), but the whole thing is a series of balanced compromises at this resolution, as we know - just as some icons don't work on black backgrounds, some fonts don't look so good greyed out. The solution - if we can't design everything to look good in all circumstances - is surely to choose our resources to best fit the occasion, which is pretty much what testing different system fonts is all about.

Edited January 8, 2014 by flashjazzcat

[+MrFish]

Yes: my first reaction was that the existing system font is damned near perfect. However, I'll put some comparisons together in a bit. One immediate effect of a small system font is that those 320x200 pixels look comparatively larger, making the interace slightly less nicely balanced.

 

Just to be clear. I was only saying that the menu font started to look large in comparison to the font being used in the window. The interface proportions belong to the font that's been designed for it and visa versa.

[flashjazzcat]

Well, I fiddled about with the alignment and scaling code (window drag bars are now of a fixed height regardless of the system font height, and the title string is vertically as well as horizontally centred. This imposes the practical limit that the system font must not be more than 11-12 point). Vertical alignment on the menu bar (and the positioning of underlining) is a little unpredictable, precisely because I'm not yet vertically aligning the fonts off the baseline, which is something I really need to get around to sorting out.

 

 

 

 

 

Obviously the above selection of fonts aren't really optimised for the role of system font (very nice though they are), since they mostly lack the special menu characters required. I wouldn't seriously consider any of these for an alternative system font, in fact, but I couldn't put my hand on a 8-9 point sans font with heavy verticals. I think the collection I have here (apart from the recent small font collection Paul kindly sent over) is a fairly motley gang derived from various font revisions (one of them caused a crash), so there's a definite need to consolidate and update the range of general purpose fonts at this end.

 

I think the excellent all-round design of the original system font is thrown into sharp relief here: Paul did a marvellous job with that, as he does with all of his designs. But this one is head and shoulders above the rest when used as a system font, mainly because it was carefully hand-crafted for the job, has a nice even weight, and includes all the necessary special characters.

 

You'll notice "Serif" and "Tekton10" actually don't look too bad greyed out, even though they have light vertical strokes. So clearly the overall size of a glyph as well as its weight has a big influence on how pleasing the dithering looks, which makes sense really. You're basically halving the number of visible pixels in a glyph when greying it out. If the glyph has 2px wide verticals (as does the system font), the effect works well, but 1px verticals (especially slanted verticals) obviously take a beating. At the end of the day it's no problem, and at least it looks consistent. The point of greyed out menu options is you can't click on them anyway. Another point worth noting is that the dynamic emboldening and italicising algorithms (the latter being rather essential, since we can't easily do "native" italics yet until we introduce kerning to the font spec) are subject to the same pitfalls as dimming. In particular, a glyph with only 1px of vertical "space" between upright strokes will be pretty much obliterated by emboldening, since the character is shifted right 1px and printed on top of itself. Conversely, slightly larger characters with 2px gaps between uprights are optimal candidates for dynamic emboldening.

 

Anyway - it's fun to play, but there are more pressing matters at hand. We definitely need more fonts with all the "special" characters in order to play with the styling, although it would perhaps be unwise for Paul to spend large amounts of time producing hand-edited fonts at the moment when there are still amendments to be made to the font format.

Edited January 8, 2014 by flashjazzcat

[+Gemintronic]

Is the GEOS API documented well enough that someday this could be compatible? I get the feeling the short answer is no and the long answer is yes

[flashjazzcat]

Is the GEOS API documented well enough that someday this could be compatible? I get the feeling the short answer is no and the long answer is yes

Nearly right: both the long and short answers are no. The GEOS API is really well documented (I have studied the docs), but the two systems are so utterly different under the hood that it would be futile to enforce any correlation between the two. The way things worked out, the API will be quite close to that of SymbOS, but with differences to cater for divergence in the UI (fixed menu bar, etc), resource handling, etc - not to mention the different CPUs and memory models. But the main thing SymbOS and the A8 GUI have in common are:

• Window and menu definitions and structs (roughly the same)
• IPC message-passing system using queues

The SymbOS developer docs are well worth a read for anyone who thinks they might be interested in developing for the A8 system. I know I keep getting nagged about writing up the API, but frankly it's not yet well defined enough to start describing the calls. But the SymbOS docs will give you a rough idea of how it's envisaged applications will be laid out. How different the kernel calls end up looking will depend on how efficient the task management ends up being on the A8.

Edited January 8, 2014 by flashjazzcat

[fibrewire]

I think the excellent all-round design of the original system font is thrown into sharp relief here: Paul did a marvellous job with that, as he does with all of his designs. But this one is head and shoulders above the rest when used as a system font, mainly because it was carefully hand-crafted for the job, has a nice even weight, and includes all the necessary special characters.

 

I concur with you regarding the original system font, and apologize for the tangent. Thanks for entertaining the exercise, and the new fonts sure are fun to look at!

 

Now, back to the code mill...

 

[Prodatron]

Great to see, how it's going on and on here! That's probably a little late, but I just want to say, that I was totally excited by the performance boost you achieved with switching to the dirty-rectangles methode.

Glad, that you like the SymbOS API and structures. Keep on the amazing work, I am looking forward to more interesting discussions in the future!

[+MrFish]

Well, I fiddled about with the alignment and scaling code (window drag bars are now of a fixed height regardless of the system font height, and the title string is vertically as well as horizontally centred. This imposes the practical limit that the system font must not be more than 11-12 point). Vertical alignment on the menu bar (and the positioning of underlining) is a little unpredictable, precisely because I'm not yet vertically aligning the fonts off the baseline, which is something I really need to get around to sorting out.

 

elles10.png

 

iconxnar.png

 

serif.png

 

tekton10.png

 

Obviously the above selection of fonts aren't really optimised for the role of system font (very nice though they are), since they mostly lack the special menu characters required. I wouldn't seriously consider any of these for an alternative system font, in fact, but I couldn't put my hand on a 8-9 point sans font with heavy verticals. I think the collection I have here (apart from the recent small font collection Paul kindly sent over) is a fairly motley gang derived from various font revisions (one of them caused a crash), so there's a definite need to consolidate and update the range of general purpose fonts at this end.

 

I think the excellent all-round design of the original system font is thrown into sharp relief here: Paul did a marvellous job with that, as he does with all of his designs. But this one is head and shoulders above the rest when used as a system font, mainly because it was carefully hand-crafted for the job, has a nice even weight, and includes all the necessary special characters.

 

You'll notice "Serif" and "Tekton10" actually don't look too bad greyed out, even though they have light vertical strokes. So clearly the overall size of a glyph as well as its weight has a big influence on how pleasing the dithering looks, which makes sense really. You're basically halving the number of visible pixels in a glyph when greying it out. If the glyph has 2px wide verticals (as does the system font), the effect works well, but 1px verticals (especially slanted verticals) obviously take a beating. At the end of the day it's no problem, and at least it looks consistent. The point of greyed out menu options is you can't click on them anyway. Another point worth noting is that the dynamic emboldening and italicising algorithms (the latter being rather essential, since we can't easily do "native" italics yet until we introduce kerning to the font spec) are subject to the same pitfalls as dimming. In particular, a glyph with only 1px of vertical "space" between upright strokes will be pretty much obliterated by emboldening, since the character is shifted right 1px and printed on top of itself. Conversely, slightly larger characters with 2px gaps between uprights are optimal candidates for dynamic emboldening.

 

Anyway - it's fun to play, but there are more pressing matters at hand. We definitely need more fonts with all the "special" characters in order to play with the styling, although it would perhaps be unwise for Paul to spend large amounts of time producing hand-edited fonts at the moment when there are still amendments to be made to the font format.

 

Thanks for taking the time to try some of those out.

 

Yes, I think our time is better spent on more pressing matters. Choosing a set of viable system fonts would be more of an issue for later down the road. However, changes in the font format itself have no bearing on me editing any of the font sets, as the editing comes before conversion to our format anyway. So if I get the time or the urge I may start adding the special menu characters to some of the other fonts - there are just a few characters anyway. One idea on that would be to eliminate the special characters from the fonts altogether, and and just have them set aside as a sort of special mini-set, since they're the same no matter what font is being used -- although I have thought about shrinking them for some of the really small fonts. This would also free up some character space in the existing fonts, and allow us to use a more standardized 256 character set for system fonts in the long run (non-system fonts are already standardized, or already planned as such).

 

Here's one more that I found from several years ago. This is the System Regular font as seen in the menus. No greying-out here...

 

Edited January 8, 2014 by MrFish

[UNIXcoffee928]

It seems to me that it would be quite useful to write a program that would batch convert whole directories of Amiga fonts, since there are a lot of them out there.

 

Are there any plans to publish the technical specifications for the font used in the Atari GUI?

 

If these specifications were to be made public, then we could plan out what is necessary to create a suitable conversion program that would allow us to gain access to a vast array of different typefaces, with minimal effort, while creating very little distraction from the main goal of honing the GUI.

[flashjazzcat]

It seems to me that it would be quite useful to write a program that would batch convert whole directories of Amiga fonts, since there are a lot of them out there.

 

Are there any plans to publish the technical specifications for the font used in the Atari GUI?

 

If these specifications were to be made public, then we could plan out what is necessary to create a suitable conversion program that would allow us to gain access to a vast array of different typefaces, with minimal effort, while creating very little distraction from the main goal of honing the GUI.

 

I know MrFish derives his fonts from a wide variety of sources, and I once described this process as something of a "black art", since I don't really know what his toolchain looks like. He also does a lot of careful hand-editing, so the fonts produced are very much stamped with his personal "signature", so to speak. We also have the font converter MrFish has written, which I can use to convert Borland BDF fonts directly to the PFT format used by the GUI. Fonts converted in this way, of course, lack the special menu characters, as well as the general "finesse" of the fonts Paul manufactures.

 

Having said all that, neither of us have had enormous amounts of time to devote to this project of late, for one reason or another, and from my point of view, we probably need all the help we can get. While a Windows/DOS version of the font converter would be useful, Paul seems pretty happy with the tools he has to hand. The font format is almost complete, but we still have a couple of ideas to try out which will result in changes to the spec. The spec's no great secret, but I wouldn't want people to start putting effort in when the design isn't 100 per cent complete, and obviously keeping changes synced when there are more cooks crowding up the kitchen might prove tricky.

 

I have an inkling of what Paul's stance on this matter would be, but I'll leave it to him to respond if he wants to. While Paul's time is well spent on resource design, toolchain development, and aesthetic considerations, I want to avoid getting too bogged down in the micro-management of visual design at the moment. There's an enormous amount of coding to do, not to mention getting the practical details of the font format nailed down. I can happily develop the system using no more that the resources I have right now for the foreseeable future, although it's hoped that a considerable resource library will be developed in parallel to the work I'm doing. It's all down to time and man hours at the end of the day.

 

To slightly change the subject, here's an alert dialogue I've just finished for the text-based UI.

 

 

I didn't like the GEM way of doing message boxes, where you define up to three fixed lines of text, so I wrote something which word-wraps a whole paragraph and sizes the alert window to suit. Moreover, the string can contain printf directives, so you can say:

	jsr Alert
	.byte 'This is an alert box. The filename is %s.',0
	.word FileName

The PRINTF routine first prints the whole expanded string to a temporary buffer, which is then word-wrapped and displayed in the dialog. Obviously the new code can be ported right across to the GUI with little alteration.

Edited January 9, 2014 by flashjazzcat

[flashjazzcat]

 

Thanks for taking the time to try some of those out.

 

Yes, I think our time is better spent on more pressing matters. Choosing a set of viable system fonts would be more of an issue for later down the road. However, changes in the font format itself have no bearing on me editing any of the font sets, as the editing comes before conversion to our format anyway. So if I get the time or the urge I may start adding the special menu characters to some of the other fonts - there are just a few characters anyway. One idea on that would be to eliminate the special characters from the fonts altogether, and and just have them set aside as a sort of special mini-set, since they're the same no matter what font is being used -- although I have thought about shrinking them for some of the really small fonts. This would also free up some character space in the existing fonts, and allow us to use a more standardized 256 character set for system fonts in the long run (non-system fonts are already standardized, or already planned as such).

 

Here's one more that I found from several years ago. This is the System Regular font as seen in the menus. No greying-out here...

 

system.png

 

Ah yes - the old System Regular font.

 

You make a good point about the special characters. An advantage of having all the special characters in the font itself is that they're then automatically always exactly the same point size as the characters surrounding them. They're also faster to render using this method. However, I'll have a look and see how other systems handled this kind of thing.

[+MrFish]

It seems to me that it would be quite useful to write a program that would batch convert whole directories of Amiga fonts, since there are a lot of them out there.

 

Are there any plans to publish the technical specifications for the font used in the Atari GUI?

 

If these specifications were to be made public, then we could plan out what is necessary to create a suitable conversion program that would allow us to gain access to a vast array of different typefaces, with minimal effort, while creating very little distraction from the main goal of honing the GUI.

 

I don't think there is any common font format out there that I can't convert right now. My conversion program will currently convert Adobe BDF fonts directly. Other font formats require one or two additional steps additional steps.

 

I recall taking a look at some Amiga fonts before and not being too impressed, with either the fonts or the depth of character/glyph coverage. Maybe I wasn't searching in the right places though. If you can give me a few good examples I'll convert them and post up the results.

Edited January 9, 2014 by MrFish

[+MrFish]

I know MrFish derives his fonts from a wide variety of sources, and I once described this process as something of a "black art", since I don't really know what his toolchain looks like. He also does a lot of careful hand-editing, so the fonts produced are very much stamped with his personal "signature", so to speak. We also have the font converter MrFish has written, which I can use to convert Borland BDF fonts directly to the PFT format used by the GUI. Fonts converted in this way, of course, lack the special menu characters, as well as the general "finesse" of the fonts Paul manufactures.

 

Having said all that, neither of us have had enormous amounts of time to devote to this project of late, for one reason or another, and from my point of view, we probably need all the help we can get. While a Windows/DOS version of the font converter would be useful, Paul seems pretty happy with the tools he has to hand. The font format is almost complete, but we still have a couple of ideas to try out which will result in changes to the spec. The spec's no great secret, but I wouldn't want people to start putting effort in when the design isn't 100 per cent complete, and obviously keeping changes synced when there are more cooks crowding up the kitchen might prove tricky.

 

I have an inkling of what Paul's stance on this matter would be, but I'll leave it to him to respond if he wants to. While Paul's time is well spent on resource design, toolchain development, and aesthetic considerations, I want to avoid getting too bogged down in the micro-management of visual design at the moment. There's an enormous amount of coding to do, not to mention getting the practical details of the font format nailed down. I can happily develop the system using no more that the resources I have right now for the foreseeable future, although it's hoped that a considerable resource library will be developed in parallel to the work I'm doing. It's all down to time and man hours at the end of the day.

 

Actually I'm not hand editing the fonts that are getting converted. I may edit a few characters where I think they need to be improved here and there. But by and large everything is going into the converter as is. The only hand editing really being done is on the fonts I'm creating myself, which will be mainly a handful of system fonts, and presents no major challenge or investment of time.

 

[Note: It's Adobe BDF, not Borland BDF.]

 

Actually I have a version of the converter written for Windows as well already, albeit not as complete as the one I've written in Turbo-BASIC yet.

 

Yes, agreed, fonts are not really of much concern at this time, other than the possible changes that are coming to the format. We already have a large number of fonts that have been hand-picked by myself, waiting to be converted. This doesn't mean we're not interested in other sources, but the subject has been covered quite thoroughly already.

[flashjazzcat]

 

Actually I'm not hand editing the fonts that are getting converted. I may edit a few characters where I think they need to be improved here and there...

 

Right, so you're doing a bit of hand editing it seems - not a lot of hand editing.

[UNIXcoffee928]

Oh, OK, you are already using a conversion program.

 

If you can give me a few good examples I'll convert them and post up the results.

 

The fonts from Dpaint IV, AmigaTerm, TextCraft, Prowrite, Excellence, and one called XEN, all come to mind, rather quickly.

All of the non-commercial Amiga fonts can be found on Aminet, right here:
http://aminet.net/search?query=font&start=0

As far as the commercial ones go, I know of no one specific font archive, however practically everything ever released is available if you go looking for "amiga collections".

 

One language that you may want to investigate for creating your own editing & conversion tools is TCL/TK. Very easy to learn, & your source can be used on Mac, Win, UNIX, Linux without modification. It is very easy to create GUI elements, and a whole application can be put together really quickly.

 

For example, you could make a program that loaded two fonts in, with different formats, displayed them, and let you edit each character, on it's own canvas. It's a super-simple matter to work with clickable lists, file requesters, any gui element. You could also assign pullldown items, or buttons to do batch converts on directories of fonts, or do conversions from your current spec 1 fonts to the proposed spec 2 fonts, etc. Other than that, it also allows you to directly integrate other languages, right from the language, itself.

 

A lot of people have forgotten about TCL/TK, but really, it is quite an awesome language (as is it's variant, "Expect"). You can get it for free through ActiveState, here:

http://www.activestate.com/activetcl

 

You'll be amazed at how fast you can take a small algorithm, and turn it into a Windowed application. Great stuff for quickly turning an idea into a usable windowed application. It pretty much lets you be as creative as you could have been with BASIC, back in the day.

 

Hope that helps you. You may be able to take your code, port it to TCL/TK, and have all of your tools available, all in one place, to save yourself some time.

[+MrFish]

Right, so you're doing a bit of hand editing it seems - not a lot of hand editing.

 

Almost none. I think I found a couple characters in one font that I thought should have a few pixels changed, and that's about it. When the time comes to do the bulk of conversions I may be a little more scrutinizing. But my intent is to pick fonts that are ready for the show as is.