Hello Ken
On 10-Jul-01, you wrote:
>> Text() cannot support this. TextFit() and TextExtent() also expect 8 bit
>> characters. diskfont.library apparently has no clue about what it's
>> doing - it only opens fonts in a very simple way. Bullet-like APIs have
>> to do all the work on AmigaOS, but as it stands there isn't a way of
>> accessing these reliably or efficiently to use Unicode texts.
>
> It would be simple enough to write an Amiga library which could load a
> set of (many!) fonts, and turn UTF16 or text with embedded α sort of
I said all this. I've researched it.. I got bored of people constantly saying
"it would be simple" when it isn't. It's not simple: there is no way of ever
making AmigaOS apps as they currently stand support Unicode fonts and
Unicode text through the current API calls.
> But, for an HTML viewer to support unicode and CSS2, it would have to be
> written from scratch. I don't see how these capabilties can be plugged in to
> the existing Amiga browsers. HTML - CSS2 - Unicode must all be written as
> an integrated total in my opinion - they can't easily be just plugged into
> each other.
There is less to be done to support unicode than you might think - the only
things requiring conversion are html entities (they'd need real codepoints
rather than latin1 ones), html attribute values (<img name="string"> -
everything between the quotes) and text that isn't a tag. V already does
this - it needs to scan these strings for entities anyway, getting the name
of the codepage from the HTTP header or a META tag is simple as hell. What
would be the difficulty in adding a Unicode conversion step from some
web codepage to some standard one, UTF8 or UTF16 let's say, usable by
a new font API?
About 10 lines of code in various places? Less than that, even..
It's not hard to get your app to talk in Unicode, they designed it that way,
and good design of a new Unicode API would make it even easier.
Unicode conversion is easy: there are free libraries for this (libiconv,
wchar, etc.) - loading fonts is easy via the outline font API - but tying
it together with support functions requires coordination.
And with so many people saying "wow, it'd be simple to.." and "we must
hack it into older apps!" I don't see how that would be possible. I've tried
sparking up discussions and it devolves into the same thing: people going
back over the stuff I've already had a look into, none with any real
knowledge of what they're going on about (Don, no, legacy apps cannot
be supported).
Is anyone actually willing to pick out some stuff and standardise on it?
Because the constant round-in-circles discussion tires me. If we need to
contact someone like Olaf Barthel (like Don says) then it's only to see if
we can coerce him into working with and agreeing on certain standards
such that they would be in future revisions of the OS without need for
compatibility layers or extra libraries. Nobody wants another API war.
Thanks
--
Matt <[EMAIL PROTECTED]>
_____________________________________________________________________
Voyager Mailing List - http://v3.vapor.com/
Voyager FAQ....: http://faq.vapor.com/voyager/
Listserver Help: mailto:[EMAIL PROTECTED]?Subject=HELP
Unsubscribe....: mailto:[EMAIL PROTECTED]?Subject=UNSUBSCRIBE
