> > only a person with a graphics card and a little memory (we're > > talking machines with 24MB or more..) would have. > > Hmm.. I take it this isn't something that could be switched on or off > with preferences? Or even seperate executables? (like the versions > optimised for different processors)?
Sure it is, but turning off something like "International Language" and "decent font support" by default is a little lame, don't you think? The greatest feature of using outline fonts directly (or semi-directly) is that you can set the DPI of the "target" - MacOS IE, Mozilla and Opera let you set the default of 72 or 96 dpi setting and so on so that incredibly tiny font sizes (7pt would be unreadable on MacOS and possibly AmigaOS) would be "scaled" up slightly. > > making a few glyphs suck up a few megabytes. Even Ken's system > > will suffer this. > > There is going to be a price to pay with any system of dealing with > glyphs. On the other hand, how many people have minimum specced > Amigas for daily use? Well we deal with glyphs right now anyway: just in 10k bitmap fonts and poorly handled outline-sourced bitmap fonts. When your entire font set is in a normal style, and your italics and bold characters are automatically generated, that's a little space saved there. I can implement real font family support now, which would leverage ttf.library features to load real Italic glyphs, via standard ordinary font APIs (i.e. load the font as "Helvetica" with italic set in the ta_Style flags and see if it comes back with the flag still set..) That feature alone would increase memory requirements threefold the moment you set a bold or italic text on a page, since all 256 iso-8859-1 glyphs are loaded. For an outline font your memory requirements are, simply: the size of every glyph you open, plus 16 bytes per glyph overhead on structures, plus possibly the size of the font if kept in memory (ttf.library will spool from disk if it is low on memory, or the font is ridiculously sized.. but a 1MB font would go into memory and stay there so that glyph generation is almost instant) The difference between using outlines, and using graphics.library etc. is that possibility of keeping the outline font in memory. Opening a normal font will load the outline to spool off 256 glyphs and then close it and free the memory. It's not nice to keep pushing and pulling it out of memory unless you're sure you're not going to use it anymore. > support those users as best as possible. If CSS requires glyphs, and > glyphs require extra memory and gfx-cards--then why not "ship" V with > that turned off? Then the user who has the extra required memory can > turn the switch. CSS doesn't require it, but we already saw that we're missing important unicode character literals &blah; and so on, and people want UTF8 support (an English page in UTF8 wouldn't be so bad.. you just end up with standard readable text and then couplets of accented characters where there is a two-byte character instead of one..) and you can't do that with plain ordinary Amiga fonts. Not even H&P's insane switch to iso-8859-15 will help you. > > have to cull your userbase for a certain feature. So much so > > that I wouldn't do it. > > For the time being, MorphOS would count me out. I don't have PPC. > This may change in the future, when MOS is a "released" product. I'm > not anti-MOS or anti-Name. As far as hardware, I hope that I find the > h/w solution to let me run both. Well MorphOS is the one I have access to. AmigaOS 4.x isn't even tentative right now in my eyes: I have yet to see proof that those screenshots they have online are actually generated by a PPC processor even. The moment I get a developer kit for it (which will probably be a few months after it gets released.. and who knows when that is?) Amithlon is a possibility since it does have huge amounts of proc power at it's disposal, and PC's generally have a lot of memory. But I don't have a copy. But if you whined for it enough, I don't see why I couldn't implement it, albeit in 68k and slow on a real Amiga, for the sole purpose of Amithlon users, or insane Amiga users. > (note, the mui smart refresh that bogs a real amiga--KILLS Voyager > under amithlon... is it using a trick of the custom chips? > Otherwise, things like FLASH move as fast as they do on the > Windows/Linux side.) Smart Refresh is simply a waste of processor time and memory. > In what context? Will it break Voyager's back, or will it squish > low-end support? Probably squish someone's brain. > I thought that Ollie rewrote V because of CSS and > other stuff down the line that would break the old V's back? I mean V is rewritten to be properly object oriented and is a highly advanced little system internally, and very easy to add CSS support to the objects we already have (even easier when the CSS attributes do the same thing as HTML 4 stuff) - but parsing CSS looks like a nightmare once you get to CSS2 and things. Where's Tom Hurst? He can give you a few special CSS tricks that are a pain to even code onto a website :P I just fear you'd get something which allows setting colours and borders and not much else for a while. I'd love to have something like changing the text inside a <span> tag dynamically. But.. it's a pain ;) Hell, we don't even enumerate <span> tags in the DOM yet. We left it out so we could see where CSS is really used ;) Dynamic menus would be possible to implement. Layers. But there be dragons in the CSS spec. I hope what you get is enough and you don't end up with something akin to the JS support on the current browsers right now ;) > certainly hope you mean old miggy support... Besides, the Vapor team > could always release V2.95/6 as the suggested browser for low-end > amigas.. But it sucks :) -- Matt
