NetSurf 3.11 has been released!

@redfox

Sounds like you are missing the list_#? images from AISS. Maybe reinstall the latest package?

I've truncated the iconified window title to 23 chars, and fixed the toolbar character set problem.

@walkero

Quote:

Will our AmigaOs4.1 ever be able to do this? Or is it the font system....I have no idea what exactly is missing maybe you could explain it briefly?

@Chris

Quote:

Great, thank you very much. Where can we find the latest fixes?

Is it already in build 6772 and they have reuploaded it. Or will there be a new test build?

@Maijestro
Quote:Unicode is fully supported by the outline font engines, even since AmigaOS 2.1 the AGFA bullet.library already supported some parts of it (16 bit only, i.e. only the first 65536 Unicode chars, and because of some different encoding even less than that).
It's more work than using the 8 bit graphics.library Text#?() functions, but for example my AmigaOS 4.x ports of OWB supported 32 bit Unicode completely.

The only important limit is that the AmigaOS outline font engines are black/white only (+ alpha sub-pixel rendering in AmigaOS 4.x).
Colour outline fonts, which are used in current web browser for emoji for example, are not supported.

utility.library and locale.library include some support for UTF-8 as well, for example the catalog translation files can, and should, use UTF-8 instead of a 8 bit charset like the default ISO-8859-15, or other language/country specific 8 bit charsets.

BOOPSI gadgets could use UTF-8, or 32 bit, Unicode as well for texts. AFAIK most (or even all?) still don't, but rendering Unicode in the webview of a browser is no problem at all.
I always tested OWB with some Chinese, Japanese and Korean web pages as well. I did't understand anything at all on such pages, but comparing the OWB results with the ones from FireFox and Chrome was enough to check that it was working correctly

@Maijestro
I believe joerg covered me.

@Maijestro

It should be here but looks like the autobuilder is offline: https://ci.netsurf-browser.org/builds/amiga/

I've uploaded my test build here in the meantime: https://www.cy2.uk/netsurf_os4_20241129.lha


In relation to UTF-8, in addition to what Joerg said, NetSurf does render the pages directly in UTF-8, but the hotlist menus and toolbar are converted to the local character set first (so as long as you have pages in your local language or English/ASCII they will display correctly).

I've tested this today with a Greek page, and the menu item and toolbar displayed the title correctly - provided of course my system was set to Greek.

@Chris
Quote:

I hope you used my amiga.gr website :D :D

@walkero

Actually the page title isn't in Greek, so it wouldn't have helped with what I was testing! :p

@Chris

Quote:

Thanks Chris.

@joerg

Quote:Sorry, joerg, for once I have to disagree with part of what you write.

Yes, .ct files can use UTF-8, but as long as we don't have any text editor on AmigaOS which supports UTF-8, they shouldn't. It's just too much hassle for translators to maintain.

Best regards,

Niels
(long time and still active translator of OS3.5, OS3.9, OS4.x and other products.)

@nbache
Quote:

Please allow me to disagree with that. There is lite-xl that is Unicode first, and it can convert texts between encodings as well.

@nbache
Even if you don't want to switch to an editor with Unicode support like lite-xl but keep using your favourite, 8 bit only, text editor there are tools like C:CharSetConvert and you can use something liketo convert it to UTF-8 before using CatComp (or replacement tools) to create the UTF-8 .catalog file from the .ct file.
Except for executing an additional command to create the UTF-8 .catalog file all you have to do is to set "## codeset" to the UTF-8 "mibenum" 106 in the .ct file.

@nbache

This will depend on the program sadly, UTF8 is not support in menus and in many places like window titles and screen titles, Icon names, but some program will support UTF8 on buttons, and other places, if the GUI is custom, in that case the language files will also need to be in UTF8 format.

@joerg, @walkero

Okay, I suppose I need to investigate these possibilities closer.

I'll put it on the todo list.

But still, many translators will be even less inclined than me to learn these tools (whether LiteXL or the extra CharsetConvert step).

LiteXL seems very capable, but I'm really not so fond of the way its user interface works. It would require a massive effort for me to learn/get used to, which i don't have time for presently. My personal ideal of a text editor is NotePad++ on Windows - if only we had that or similar.

Best regards,

Niels

@LiveForIt

If I have understood it correctly, the program wouldn't need to know anything about the UTF-8 .catalog. Locale would take care of that and give the program the string converted to the current system charset. Or what?

Best regards,

Niels

@nbache
By default locale.library converts the strings from the charset of the .catalog to the system default one. If it's not possible to convert a char because it's not in the destination charset you get a '?'.
Using the OC_WantedCodeSet tag of OpenCatalog[A]() the program can get the strings in a different charset, incl. UTF-8 (106).

In case the MIBenums are not in the locale.library docs: AmigaOS 4.x uses the IANA standard https://www.iana.org/assignments/chara ... sets/character-sets.xhtml
Additionally to the internal UTF-7/8/16/32 ones only the 8 bit charsets stored in L:Charsets are supported. Missing ones can be created with C:BuildMapTable.

@LiveForIt
You could open the catalog twice, for exampleUse the strings from catalog_utf8 in the parts of your program supporting Unicode and the strings from catalog_8bit for parts like menus, window/screen titles, etc. which only support 8 bit strings.

@nbache

If the developer has decided to support chines, Korean, Japanese there is no way fit it into a codepage, as code page can only have 256 symbols. And lot of these symbols are reserved, it’s really above value of128 that you have language specific codes, anything below 128 is reserved for US ASC 7Bit, in chines there is 20,000 symbols in use, that wont fit in upper 128 to 256 ramining locations in the table.

You can convert from ASC2 8Bit to UTF8 without loss, but you can’t convert from UTF8 to ASCII without loss.

One of the major benefits of UTF8 is, that program can technically also display multiple languages at the same time. Perhaps you have a document written in French and Danish.

I think for developers, this mostly the annoying thing that can done better, and there is no good reason not to support UTF8. at least at simplest metods.

I doubt most of developers know chines, Korean, Japanese, and there is not a lot of users from these countries.

If there is an good reason for it, is most be not degrading the documents to jibbery gook. You made changes to a document or file. a lot of source code is actually in UTF8. If document is edited in ASCII editor, it can result in illegal symbols, in that case the source code wont compile.

@nbache

There's an open source reimplementation of Notepad++, it needs Qt5 though so not an easy port. https://github.com/dail8859/NotepadNext

@Chris
Quote:We have https://github.com/elfpipe/amiga-qt6
Probably misses a lot of parts available on other OSes, but might be worth a try?

deleted double post