Re: [Freedos-user] Unicode
Hi all, >> Still I think UTF-8 aware KEYB and DISPLAY together with old apps >> are still a lot more useful than any "you always have to use 16 bit >> wide characters" method which would only work with new apps at all. > KEYB would need no changes, 2-char wide characters would be a String. > True that not too comfortable to write the corresponding KL layouts, > but still feasible. It means I can use !1, !2, etc... on KEY files and create strings. I see, according to documentation, that I can prepare up to 79 strings. I'd like to prepare a prototype brazilian keyboard layout and try it with Mined. I have just a question, Aitor - how to deal with dead keys and strings? Can the resulting combination point to a string? Just an example: 26 !C1 (...) <-- !C1 Pointing to acute-accent combinations in this case (brazilian keyboard) (...) [Diacritics...] ´ aá <-- Here is my doubt - Could I make "a!1"? [Strings...] !1 Bytes_related_to_á_in_UTF-8 Cheers, Henrique -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode
That should work, try it out and let me know. There's a bug with strings that I am fixing already, though. If it doesn't work, I'll have the 2.01 beta soon. Aitor 2011/7/9 Henrique Peron : > Hi all, > >>> Still I think UTF-8 aware KEYB and DISPLAY together with old apps >>> are still a lot more useful than any "you always have to use 16 bit >>> wide characters" method which would only work with new apps at all. >> KEYB would need no changes, 2-char wide characters would be a String. >> True that not too comfortable to write the corresponding KL layouts, >> but still feasible. > It means I can use !1, !2, etc... on KEY files and create strings. > I see, according to documentation, that I can prepare up to 79 strings. > I'd like to prepare a prototype brazilian keyboard layout and try it > with Mined. > > I have just a question, Aitor - how to deal with dead keys and strings? > Can the resulting combination point to a string? > Just an example: > > 26 !C1 (...) <-- !C1 Pointing to acute-accent combinations in this case > (brazilian keyboard) > > (...) > > [Diacritics...] > ´ aá <-- Here is my doubt - Could I make "a!1"? > > [Strings...] > !1 Bytes_related_to_á_in_UTF-8 > > Cheers, > Henrique > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode
I'll try it and let you know. Meanwhile, let me tell you that I'll need room for 142 strings. I explain. VISCII (Vietnamese Extended ASCII) comprehends all the set of 134 precomposed vietnamese accented letters. I made it available for FreeDOS (along with the corresponding keyboard layout) a long time ago. It is (as you can see) so huge that not only has VISCII no room for linedraw, shade, block or those few mathematical characters common on most codepages but it has to "invade" the lower half of the codepage (the regular ASCII area) and redefine the glyphs which represent 6 less used control characters in the range 00-1Fh. (Who said "less used" on those old DOS days? The vietnamese did. It is not my call. I just followed suit.) No foreign chars (from a vietnamese point-of-view) are present. There is TCVN-5712, another vietnamese encoding. It includes non-breaking space and the 5 combining diacritical marks used in vietnamese (for those who use properly tailored vietnamese text editors able to work with combining chars - or, nowadays, Mined), pushing 6 precomposed vietnamese accented letters to the 00-1Fh area. Finally, there is VPS, yet another vietnamese encoding. It includes non-breaking space, left and right single quotation marks and 5 non-vietnamese precomposed accented letters on the upper half of the encoding, pushing 8 vietnamese precomposed accented letters to the 00-1Fh area. In total, regardless of being vietnamese or not (which is irrelevant to this discussion), we have 142 characters which will need to be represented through strings because (most of them) are composed of 3 bytes each (being above Unicode's codepoint 07FFh) and a few of them are composed of 2 bytes each (above Unicode's codepoint 007Fh, below 0800h). Henrique Em 11/07/2011 18:11, Aitor Santamaría escreveu: > That should work, try it out and let me know. > There's a bug with strings that I am fixing already, though. If it > doesn't work, I'll have the 2.01 beta soon. > > Aitor > > 2011/7/9 Henrique Peron: >> Hi all, >> Still I think UTF-8 aware KEYB and DISPLAY together with old apps are still a lot more useful than any "you always have to use 16 bit wide characters" method which would only work with new apps at all. >>> KEYB would need no changes, 2-char wide characters would be a String. >>> True that not too comfortable to write the corresponding KL layouts, >>> but still feasible. >> It means I can use !1, !2, etc... on KEY files and create strings. >> I see, according to documentation, that I can prepare up to 79 strings. >> I'd like to prepare a prototype brazilian keyboard layout and try it >> with Mined. >> >> I have just a question, Aitor - how to deal with dead keys and strings? >> Can the resulting combination point to a string? >> Just an example: >> >> 26 !C1 (...)<-- !C1 Pointing to acute-accent combinations in this case >> (brazilian keyboard) >> >> (...) >> >> [Diacritics...] >> ´ aá<-- Here is my doubt - Could I make "a!1"? >> >> [Strings...] >> !1 Bytes_related_to_á_in_UTF-8 >> >> Cheers, >> Henrique >> >> -- >> All of the data generated in your IT infrastructure is seriously valuable. >> Why? It contains a definitive record of application performance, security >> threats, fraudulent activity, and more. Splunk takes this data and makes >> sense of it. IT sense. And common sense. >> http://p.sf.net/sfu/splunk-d2d-c2 >> ___ >> Freedos-user mailing list >> Freedos-user@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/freedos-user >> > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode support in languages
I doubt you will find any DOS language that supports Unicode 'out of the box'. However, there are Unicode-enabled DOS programs out there, so I'd say your best shot is to take a look inside them. Blocek is a unicode editor written in Pascal: http://www.laaca-mirror.ic.cz/ FoxType is a UTF8 text viewer written in FreeBasic: http://www.viste-family.net/mateusz/dos/en/foxtype.htm bye, Mateusz On Friday 13 April 2012 16:33:30 Alex wrote: > Just to save me some time, instead of going through all the forums and > the documentation files (which would take forever), I ask this > question to you all: which of the (FreeDOS-based) languages support > Unicode? > > More specifically, does anyone know if Turbo Pascal can support UTF-8? > Is there any library/module for this purpose? > > Thanks to all in advance > > Alex -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode support in languages
El 13/04/2012 10:03 a.m., Alex escribió: > Just to save me some time, instead of going through all the forums and > the documentation files (which would take forever), I ask this > question to you all: which of the (FreeDOS-based) languages support > Unicode? > > More specifically, does anyone know if Turbo Pascal can support UTF-8? > Is there any library/module for this purpose? > > Thanks to all in advance > > Alex > > -- > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > Classic DOS on text mode can show on screen codepages with 256 charaters (1 byte per character). Not sure but I think this is a hardware limitation on the original x86 systems that was never changed because everybody moved to graphics mode. Would be great have hardware with support text modes with 2 bytes per character (256*256 = 65.536 characters per codepage) Your programs on graphics mode can emulate unicode painting any character on screen. Read this page (old): http://czyborra.com/unifont/ On this page explain a method to codify complex characters on a nice Hex format that you draw on the screen. The complete original font is here: http://czyborra.com/unifont/unifont.hex.gz Based on Mr Czyborra's work, some people has been working on it with a lot of enhacements. www.unifoundry.com -- -- +-+-+-+-+-+-+-+ Marco A. Achury Tel: +58-(212)-6158777 Cel: +58-(414)-3142282 Skype: marcoachury http://www.achury.com.ve -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode support in languages
El 13/04/2012 10:14 a.m., Mateusz Viste escribió: > I doubt you will find any DOS language that supports Unicode 'out of the box'. > However, there are Unicode-enabled DOS programs out there, so I'd say your > best shot is to take a look inside them. > > Blocek is a unicode editor written in Pascal: > http://www.laaca-mirror.ic.cz/ > > FoxType is a UTF8 text viewer written in FreeBasic: > http://www.viste-family.net/mateusz/dos/en/foxtype.htm > > bye, > Mateusz > > Euphoria language uses atoms with 2 bytes per character, so the sequences used to store text support values from 0 to 65536, and you can manipulate them with any of the standar text functions. The problem is to print characters, you can use the Czyborra's method I explain on prior mail -- -- +-+-+-+-+-+-+-+ Marco A. Achury Tel: +58-(212)-6158777 Cel: +58-(414)-3142282 Skype: marcoachury http://www.achury.com.ve -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode support in languages
Hi, On Fri, Apr 13, 2012 at 9:33 AM, Alex wrote: > > Just to save me some time, instead of going through all the forums and > the documentation files (which would take forever), I ask this > question to you all: which of the (FreeDOS-based) languages support > Unicode? > > More specifically, does anyone know if Turbo Pascal can support UTF-8? > Is there any library/module for this purpose? What exactly do you want it to do? No, there's probably no generic library (though I might be wrong, haven't looked everywhere), but it can't be too hard if you don't set impossible goals for yourself. Realistically, if you could figure out what specific languages you "mostly" want to support, you'd simplify things a lot. (Or do you really really want to support CJK ???) Or if you don't need to display fonts, only en/decode the text, it would be simpler. Most people would probably just handle 8-bit text and convert that to/from Unicode manually when necessary. P.S. So no, I don't know (offhand) of any DOS compiler "fully" supporting wchar_t or similar, sadly, but maybe I'm wrong, I haven't really messed with it barely. Turbo Pascal makes it a bit harder, maybe, but if you can live with FPC or GPC, you could maybe?? use Allegro and AllegTTF: http://www.deleveld.dds.nl/allegttf.htm -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode support in languages
My FLTK/Xlib port supports Unicode and truetype fonts. This allows to use Unicode character sets with DJGPP. Georg http://code.google.com/p/nanox-microwindows-nxlib-fltk-for-dos/ -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?
On 23/06/2023 01:02, Eric Auer wrote: PS: For all things NOT mentioned above, I expect no support for Unicode or conversions at all. I expect those to just assume an 8-bit encoding in text (and file names) matching your codepage. For the sake of completeness I will add that AMB has "some" UTF-8 support, in the sense that the human writer can create original content in utf-8, and then ambpack is able to translate it to a codepage back and forth using mappings generated by utf8tocp. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?
I added some limited Unicode support to mTCP Telnet and mTCP IRCjr in the last release a few months ago. - I used a text file to store the mapping. That lets people add code points or make corrections if they don't like the choices I made. - The code uses the text file both ways; to figure out what Unicode code point to send for a local high-bit character and what character to display when a Unicode code point is detected. - The current mapping is pointed to by a text file. - I don't try to detect the current code page in use. The user is responsible for pointing at the correct text file. While simple, this is also flexible. - I used a hash table to make the mappings pretty fast. (I've seen some horrible code that did linear searches of a table, and that's painful to sit through.) A centralized mapping would be nice, but then you will run into the question of how strict you want the code to be. The conversion from the current code page to Unicode should always be strict as Unicode has far many more glyphs. But incoming Unicode can be mapped loosely or strictly, and in my case I went for loose because I wanted the output to be useful to humans and not full of "tofu" characters. A strict mapping can be shared but a loose mapping is probably best application specific. -Mike ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode and codepages in apps already bundled with FreeDOS?
On 24/06/2023 02:18, Michael Brutman via Freedos-user wrote: A centralized mapping would be nice, but then you will run into the question of how strict you want the code to be. In an ideal world, one could imagine a new nlsfunc service that answers with a best effort match from the local codepage for any unicode codepoint. I am not saying this is a good practical idea, though. Given the limited development nowadays, it is probably for the best that each application comes with its own rules and mappings. Mateusz ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard insome computers')
> IMHO, TSR's have a lot of advantages over device drivers, and can still be > installed in CONFIG.SYS if you actually want/need to do that (with the > INSTALL= option). You can even write a single executable which can be loaded both as "device driver" (DEVICE= or DEVLOAD) and as normal program (INSTALL= or just usual execution). (Technical details in the next two paragraphs, skip at your leisure.) The easy way to do that is to utilize MZ (.EXE) format files that have another entry point specified in the header than (relative) address 0, because for "device driver" executables address 0 must contain the device header. A more interesting (though usually not necessary) way to do that is to realize that device loaders (including the one that's part of DOS's initialization code) don't actually use the "next header" pointer in the device header until after the initialization call returns. This allows one to initialize a part of that field with a jump instruction in the source code, which will be executed if the flat (.COM) format file is executed as a normal program. The device initialization code of course needs to overwrite the jump instruction with something else before returning to DOS's device loader. Most programs could already be loaded earlier in CONFIG.SYS if they were adjusted in that way, though some of the DOS structures aren't available yet in that case. Regards, Christian -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi,
On 7/5/11, Henrique Peron wrote:
>
> Before I forget, I noticed that you do use ISO codepages.
> I'll work on distinct packs of codepages and keyboard layouts for ISO
> 8859-1 ~ 16.
Honestly, I very rarely use only Latin-3 (913), so please don't waste
500 hours on my account! ;-) It's very low priority. Minimum
"good" set would be Latin 1-4 (IMHO) and perhaps Latin-15 (or whatever
is Latin-1 with Euro, I never can remember, Latin-9 or ISO 8859-15 or
???).
>>> While Unicode is huge, DOS keyboard layouts tend to be limited to
>>> Latin and Cyrillic and some other symboly which is a tiny subset.
>
> Nowadays, FreeDOS is able to work with the latin, cyrillic, greek,
> armenian and georgian alphabets, the cherokee syllabary and japanese.
You are a one-man marching band!! You've done such good work here for us! ;-)
>> Right-to-left might be hard to do (I guess?), but technically as long
>> as they can see and enter what they want, I'm sure they can get used
>> to left-to-right.
>>
> Excuse me? How can anyone type the arabic, syriac or hebrew abjads from
> left to right? *That* would be really exotic, if ever possible! :-)
How can anybody play guitar upside down or wrong-handed? But people do
it!!! ;-)
kool m'i gnipyt siht sdrawkcab thgir won (ylwols)
BTW, last I heard, Eli Z. was working on bidi editing in GNU Emacs.
> Visually speaking, if an eventual reader doesn't know hebrew (or
> yiddish, or ladino, etc.), he might not know if a text is correctly
> (right-to-left) or incorrectly (left-to-right) typed because the letters
> don't connect to each other. On the other hand, abjads like arabic and
> syriac have most of their letters shaped in a way that they connect to
> each other - always from right to left.
I'm just saying, supporting the actual chars themselves being entered
and displayed is better than nothing, even if it's forced left to
right for simplicity (or technical limitations). Not ideal, but I'm
sure they can get used to it. But I don't honestly know what KEYB does
(or could) support in that area. I'm just trying to be pragmatic /
realistic.
> UTF-8 is best suited for languages written with the latin alphabet
I just don't know if such a bias really is universally accepted or
not. As we've seen, it's not exactly "universal" which Unicode method
is preferred. I guess it matters less these days with Java being
ubiquitous and RAM being humongous.
4). Arabic (easy??)
>>> Unicode lists maybe 300 chars for that, at most.
>
> If we restrict ourselves to the arabic language, I can tell you that it
> is much less.
We don't need to support "everything", just enough for reasonable functionality.
> If we mean the arabic abjad - and then it comes around 100 languages
> ,... I can tell you that we're talking about much more than 300 chars.
Hmmm, annoying but no huge surprise.
> If we multiply the number of conjuncts by the number of abugidas in the
> indian subcontinent, we easily have thousands of distinct glyphs.
Ugh! Heheheh, nobody said i18n was easy. ;-)
> My conclusion: either there was a wholly tailored MS/IBM-DOS for India
> on those days or there were particular COM/EXE programs that would put
> any regular DOS on graphics mode so to handle ISCII.
See Hindawi@FreeDOS. (Haven't checked, but it sounds like it uses
Allegro for gfx.)
> Important to mention is that english is generally regarded as
> "pure-ASCII" but we must consider the fair amount of foreign words (like
> "café") and the need of accented/special chars used in middle and old
> english, therefore the english language (as much as german, french or
> any other latin-alphabet-based language) also falls in the same
> situation as portuguese.
Well, except that almost nobody puts accents on English words, even
loan words. At least I never do. "naive" and "cafe" have to suffice
for me. ;-)
BTW, surely I'm not telling you anything you didn't already know, but
... Old English is, erm, kinda like dead and old and 100%
incomprehensible and not used and stuff. (Beowulf?) :-))Middle
English is just weird spelling and archaic words (Shakespeare?
Chaucer?), hence we're not exactly using it a lot either. ("Anon!
Forewith she shewn the waye!")
I guess it matters more in languages where (lacking) accents changes
the meaning of words (E-o: si, sxi ... horo, hxoro ... salto, sxalto
... ktp. ktp. ktp.). But English is already weird with homonyms (wind,
bow), ambiguous stuff, or whatever.
> In what comes to storage (and UTF-8), russian needs the regular latin
> digits (1 byte each) and the cyrillic letters (2 bytes each char); if we
> think on cyrillic needs in general, then we also have the ukrainian
> hryvnia currency sign, a 3-byte char (again, "Currency Symbols",
> 2000h-206Fh).
I don't know why it isn't acceptable to just spell it out as "30
hryvnia" instead of always having specific symbols for everything.
own scripts are a problem, not to mention those like CJK that have
thousands of special ch
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Saluton! Em 05/07/2011 18:25, Rugxulo escreveu: >> Before I forget, I noticed that you do use ISO codepages. >> I'll work on distinct packs of codepages and keyboard layouts for ISO >> 8859-1 ~ 16. > Honestly, I very rarely use only Latin-3 (913), so please don't waste > 500 hours on my account! ;-) It's very low priority. Minimum > "good" set would be Latin 1-4 (IMHO) and perhaps Latin-15 (or whatever > is Latin-1 with Euro, I never can remember, Latin-9 or ISO 8859-15 or > ???). My friend, it is always a pleasure. I do hope that end-users have as much fun using "my" codepages and keyboard layouts as I have while making the necessary researches and working on them. :) ISO 8859: good part of the job is already done (the codepages) - for a long time already, by the way. All I need now is to work on distinct versions of all the keyboard layouts which could work with ISO codepages; if it takes 500 hours to get the job done, don't worry. I won't bill you. ;-) Latin-1 with Euro, on ISO, is "Latin-9", a.k.a. ISO 8859-15. While Unicode is huge, DOS keyboard layouts tend to be limited to Latin and Cyrillic and some other symboly which is a tiny subset. >> Nowadays, FreeDOS is able to work with the latin, cyrillic, greek, >> armenian and georgian alphabets, the cherokee syllabary and japanese. > > You are a one-man marching band!! You've done such good work here for us! > ;-) Thank you for your words (on the good work) but we know that it is not quite a "one-man marching band" - without Aitor's KEYB/KC/KLIB/DISPLAY and Eric's MODE, I couldn't have done anything. hehehe!! :) Besides, there is this one case which I didn't participate in: support for japanese. This oneis not "my child". It was teamwork directly between Aitor and a japanese end-user. Not only I don't even remotely have knowledge on japanese kanji (so to work on japanese codepages) but I also don't have the necessary hardware to test it. You can see for yourself: http://homepage3.nifty.com/sandy55/Video/PS55_DA.html It turns out that, when/if there's a korean or chinese FreeDOS user, I won't be able to help him at all. I'm seriously curious about how Johnson Lam deals with that, by the way. >>> Right-to-left might be hard to do (I guess?), but technically as long >>> as they can see and enter what they want, I'm sure they can get used >>> to left-to-right. >> Excuse me? How can anyone type the arabic, syriac or hebrew abjads from >> left to right? *That* would be really exotic, if ever possible! :-) > > How can anybody play guitar upside down or wrong-handed? But people do > it!!! ;-) > > kool m'i gnipyt siht sdrawkcab thgir won (ylwols) hehehe!!! However, your example exactly matches the hebrew case - Letters which don't visually connect to the next one. Therefore, it's just a matter of reading it in a proper way. In what comes to the arabic abjad, the visual aspect if trying to type it left-to-right is not even worth to discuss. (I can't resist it: playing the guitar upside down is just a matter of training and "wrong-handed" is just wrong if you don't shift the position of the strings and, of course, training - more on that, please check with Paul McCartney! :-))) > BTW, last I heard, Eli Z. was working on bidi editing in GNU Emacs. H... I don't know Eli Z. nor GNU Emacs. Just a moment. Let me google it. (Sandwatch rolling) Oh, ok! Great! Interesting! However, I didn't find any mention to "BIDI", "arabic", "hebrew", "right", "left", etc. on his webpage. Perhaps BIDI is a work in progress, as you said. Mined has support for "poor man's BIDI" (Thomas Wolff's, the developer, own words). Arabic letters (for the arabic language) can have up to 4 different shapes, according to the position in a word (initial, medial, final) or if it is isolated (as on an acronym). On graphical environments, you only find the isolated shapes of the letters on the keyboard. However, as you type them, the operating system dynamically and continously replaces the shapes of the letters for the proper ones. Let me take the arabic word "qamar" (moon), for instance. For reasons not relevant to the scope of this conversation (and particularly concerning this word), "a" is not written, therefore we type "qmr". a) You type "qaf" (the arabic letter equivalent to our "q"). The screen displays the isolated shape of it. b) You don't press ; now you type "meem" (the arabic equivalent to our "m"). Since you hadn't pressed , the operating system understands that "qaf" was the first letter of a word. It replaces its isolated shape for its initial shape. Well, there's another letter to come: "meem". There's already a letter in a initial position, therefore letter "meem" can only come on its final shape. End of word. c) You still don't press ; now you type "ra". Yes, their "r". Since once again you hadn't press , the operating system understands that "meem" wasn't the last letter of the word, after all. It trades its sha
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Saluton, On 7/6/11, Henrique Peron wrote: > > Em 05/07/2011 18:25, Rugxulo escreveu: >> >> Honestly, I very rarely use only Latin-3 (913), so please don't waste >> 500 hours on my account! ;-) It's very low priority. > > My friend, it is always a pleasure. I do hope that end-users have as > much fun using "my" codepages and keyboard layouts as I have while > making the necessary researches and working on them. :) It's cool to me to see when other languages work. It just seems almost magical. And of course I consider compilers a similar breed of magic. (But it can be complicated!) > ISO 8859: good part of the job is already done (the codepages) - for a > long time already, by the way. All I need now is to work on distinct > versions of all the keyboard layouts which could work with ISO > codepages; if it takes 500 hours to get the job done, don't worry. I > won't bill you. ;-) No pressure!! "Little by little does the trick." > Latin-1 with Euro, on ISO, is "Latin-9", a.k.a. ISO 8859-15. Which is completely logical (facepalm)! >> You are a one-man marching band!! You've done such good work here for us! >> ;-) > Thank you for your words (on the good work) but we know that it is not > quite a "one-man marching band" - without Aitor's KEYB/KC/KLIB/DISPLAY > and Eric's MODE, I couldn't have done anything. hehehe!! :) Okay, yes, forgot about Eric and Aitor, heheh. Yes, of course they've done tons, Jim too (and Bart and Japheth and Blair and Steve and Jeremy and Tom and Stefan and Rene and Bernd and ...). > Besides, there is this one case which I didn't participate in: support > for japanese. This one is not "my child". It was teamwork directly > between Aitor and a japanese end-user. Not only I don't even remotely > have knowledge on japanese kanji (so to work on japanese codepages) but > I also don't have the necessary hardware to test it. Nor do most of us, which is an annoying problem (no suitable hardware). It's almost insurmountable when you can't find any way to test. > It turns out that, when/if there's a korean or chinese FreeDOS user, I > won't be able to help him at all. I'm seriously curious about how > Johnson Lam deals with that, by the way. No idea. I almost would suggest to just let CJK users handle it themselves since it's so complex. I mean, they understand their needs better than us! Or perhaps they'll chime in here eventually. >> BTW, last I heard, Eli Z. was working on bidi editing in GNU Emacs. > > H... I don't know Eli Z. nor GNU Emacs. Just a moment. Let me google > it. (Sandwatch rolling) > > Oh, ok! Great! Interesting! However, I didn't find any mention to > "BIDI", "arabic", "hebrew", "right", "left", etc. on his webpage. > Perhaps BIDI is a work in progress, as you said. Here's what he said on news://comp.os.msdos.djgpp (May 27): "[M]ost of my scarce resources are taken anyway (adding bidirectional editing support to Emacs)." He does (apparently?) live in Israel (.il), so presumably he speaks Hebrew (right to left). Sadly, I don't, so I can't help him. Note that I have no idea if the DJGPP port of Emacs will ever support it (or ever be updated again), honestly, but he did just finish / package 23.3 for us recently. Though GNU Emacs in DOS doesn't really "display" anything special, it just fakes it via "c>" for "c with circumflex". > Mined has support for "poor man's BIDI" (Thomas Wolff's, the developer, > own words). Yes, Mined has lots of good stuff. It's a true gem for FreeDOS. >>> UTF-8 is best suited for languages written with the latin alphabet >> >> I just don't know if such a bias really is universally accepted or >> not. > > All I said is that UTF-8 is best suited for languages written with the > latin (also cyrillic, greek, georgian, armenian) alphabet; Yes, UTF-8 vs. UCS-2 both have advantages and disadvantages. I wasn't trying to be polemic, sorry, just saying, we don't need 1000 different Unicode variants or we're no better off, right?? I mean, if *nix had its way, everybody would use UTF-8, but that's not the case (Windows uses UTF-16). > Too late. I prepared the vietnamese VISCII and keyboard layout for > FreeDOS a long time ago, as a matter of fact. :) Good stuff! Too bad I can't read it. ;-) There actually used to be a fairly sizable community around here (not including me, I'm not a member, heh), but I don't know where they went. In other words, I can't grab 'em to test for ya (doh). BTW, not to get too off-topic, but whenever I want to see what a language looks like, I check here (1697 languages, wow). Easily one of the coolest sites on the Internet, even if you're not religious. http://www.christusrex.org/www1/pater/JPN-vietnam.html The computer programmer's alternative is here: http://www.99-bottles-of-beer.net/ >> For good or bad, it's long been assumed by most developers that >> everybody has VGA or SVGA or newer. (With "modern" OSes, it's worse: >> gfx acceleration, OpenGL, DirectX 9, etc.) > > Well then, let's go graphi
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi I don't know much (anything) about unicode but, Right-to-left might be hard to do (I guess?), but technically as long as they can see and enter what they want, I'm sure they can get used to left-to-right. >>> Excuse me? How can anyone type the arabic, syriac or hebrew abjads from >>> left to right? *That* would be really exotic, if ever possible! :-) >> How can anybody play guitar upside down or wrong-handed? But people do >> it!!! ;-) >> >> kool m'i gnipyt siht sdrawkcab thgir won (ylwols) > hehehe!!! However, your example exactly matches the hebrew case - > Letters which don't visually connect to the next one. Therefore, it's > just a matter of reading it in a proper way. In what comes to the arabic > abjad, the visual aspect if trying to type it left-to-right is not even > worth to discuss. (I can't resist it: playing the guitar upside down is > just a matter of training and "wrong-handed" is just wrong if you don't > shift the position of the strings and, of course, training - more on > that, please check with Paul McCartney! :-))) Would chaining interrupt 0x10 be reasonable? If I am not mistaken the FreeDOS kernel uses interrupt 0x10 function 0x0E to print characters to the screen. A TSR could be written to handle function 0x0E and pass the other functions to the BIOS. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi Jeffrey, > Would chaining interrupt 0x10 be reasonable? If I am not mistaken the FreeDOS > kernel > uses interrupt 0x10 function 0x0E to print characters to the screen. A TSR > could be > written to handle function 0x0E and pass the other functions to the BIOS. Of course. In the old days of bad BIOS implementations, there were TSRs which hooked int 10 functions 0, 2, 9, e and maybe a few more to replace them with faster implementations, but nobody stops you from replacing them with a, "graphical unicode font" implementation. You can also use a DISPLAY driver which hooks the CON device, but fewer apps might use that. The default CON of FreeDOS should use int 10 anyway, so hooking those would cover both... On the other hand, apps which like to control their screen layout in a quick and dirty way (or just want fast screen updates) will write the text mode memory (array of chars and colors) directly anyway so to cover even those, you would have to poll that memory or use a protected mode trap to be able to react when that array changes. HOWEVER, the array, int 10 and CON are all officially assuming a "one byte is one character" scenario so your layout is likely to get messed up when you use UTF-8 and you cannot use UTF-16 anyway. You could create a variant of int 10 where the upper half of some 32 bit register contains UTF-16, but most apps would not use it. This is why I think it is acceptable to have a messy layout with old apps (feeding them with UTF-8 while they believe it is not) and making some newer apps UTF-8 aware, which means aware of the fact that in UTF-8, one char in layout can be 2 or more bytes. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi Eric, > HOWEVER, the array, int 10 and CON are all officially assuming a > "one byte is one character" scenario so your layout is likely to > get messed up when you use UTF-8 and you cannot use UTF-16 anyway. In color text modes, alternating bytes are used for character and attribute. So if you were willing to sacrifice color could you use then both bytes for UTF-16? But function 0x0E does not have a parameter for attribute. So the second byte would have to be specified a different way. Or use function 0x09 or 0x0A. Also chaining interrupt 0x10 to display text right to left is harder than I expected. I'll keep working on it though. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi Jeffrey, >> HOWEVER, the array, int 10 and CON are all officially assuming a >> "one byte is one character" scenario so your layout is likely to >> get messed up when you use UTF-8 and you cannot use UTF-16 anyway. > In color text modes, alternating bytes are used for character and attribute. > So if you were willing to sacrifice color could you use then both bytes... This ia a hardware thing. The widest characters that you can get is using one bit of the color for selecting a "font page", allowing a total of 512 different characters to be displayed... But then again software which writes to the b800: array ASSUMES that exactly 1 byte is color and 1 byte is the character... Only software which is explicitly written for that uses the extra bit of 9 bit characters. > But function 0x0E does not have a parameter for attribute. So the second byte > would have to be specified a different way. Or use function 0x09 or 0x0A. As said - IF you only want to support software which is re-compiled to explicitly support some wide char extensions, you could say that e.g. the upper 16 bits of EAX are the character, instead of only AL. If you want to stay at least partially compatible with old software then UTF-8 is a good idea because that only transports one byte at a time, combining wide characters from multiple bytes when needed. The only problem with that is that as said, it breaks the layout of old software. For example old software can easily process some UTF-8 string with 10 bytes which is displayed by UTF-8 aware displays as 7 characters of which a few are accented, Japanese or whatever, but that older software will BELIEVE that the string will look 10 characters long on screen instead of the actual 7. Also, if you edit the string in the old software, you may have to remove several "characters" which are in fact just bytes before you have removed 1 Unicode character. In the other direction, if old software asks you to type at most 7 characters and your UTF-8 aware keyboard driver sends 10 "chars" to represent the 7 Unicode characters that you are trying to type, of course the old software will only accept the first 7 bytes there, which could be for example 5 and a half Unicode chars in UTF-8... Still I think UTF-8 aware KEYB and DISPLAY together with old apps are still a lot more useful than any "you always have to use 16 bit wide characters" method which would only work with new apps at all. Eric -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hi Eric, My main point was to use 0x10 to allow right to left display of Unicode for Arabic, Syriac, Hebrew etc. If each application processes its own input and output and we are only concerned with displaying their output, then whether they use 0x10 or write directly to video memory is irrelevant. > As said - IF you only want to support software which is re-compiled > to explicitly support some wide char extensions, you could say that > e.g. the upper 16 bits of EAX are the character, instead of only AL. I didn't mean to suggest only supporting new applications, only a way to display right to left. > This ia a hardware thing. The widest characters that you can get is > using one bit of the color for selecting a "font page", allowing a > total of 512 different characters to be displayed... But then again > software which writes to the b800: array ASSUMES that exactly 1 > byte is color and 1 byte is the character... Only software which is > explicitly written for that uses the extra bit of 9 bit characters. Obviously any application that writes directly to video memory will already be fixed to display left to right ( or depending on its origin right to left ) and int 0x10 could not change this. Sorry for any misunderstanding Jeffrey -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Hello, 2011/7/7 Eric Auer : > Still I think UTF-8 aware KEYB and DISPLAY together with old apps > are still a lot more useful than any "you always have to use 16 bit > wide characters" method which would only work with new apps at all. KEYB would need no changes, 2-char wide characters would be a String. True that not too comfortable to write the corresponding KL layouts, but still feasible. As for DISPLAY: MS-DISPLAY is a true enhancement of CON, but FD-DISPLAY is not (yet). Appart from turning DISPLAY into a DOS device driver and override kernel's CON, but not only IOCTL, but also write. However, it would still let out: - int 10h users - direct video BIOS writers but would be a begining. Am I letting anything out? Aitor -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
> Appart from turning DISPLAY into a DOS device driver and override > kernel's CON, but not only IOCTL, but also write. FWIW, you don't actually need to turn DISPLAY into a device driver in order to replace/enhance CON. You can do that with a TSR also. See my USBPRINT if you want an example of how -- it "replaces" the default LPT1-LPT3, adds LPT4-LPT9, and even passes calls through to the old LPTx in situations where that is needed. IMHO, TSR's have a lot of advantages over device drivers, and can still be installed in CONFIG.SYS if you actually want/need to do that (with the INSTALL= option). -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
I'm curious, you check the LoL to get the pointers and override it? Aitor 2011/7/10 Bret Johnson : >> Appart from turning DISPLAY into a DOS device driver and override >> kernel's CON, but not only IOCTL, but also write. > > FWIW, you don't actually need to turn DISPLAY into a device driver in order > to replace/enhance CON. You can do that with a TSR also. See my USBPRINT if > you want an example of how -- it "replaces" the default LPT1-LPT3, adds > LPT4-LPT9, and even passes calls through to the old LPTx in situations where > that is needed. > > IMHO, TSR's have a lot of advantages over device drivers, and can still be > installed in CONFIG.SYS if you actually want/need to do that (with the > INSTALL= option). > > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > ___ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
> I'm curious, you check the LoL to get the pointers and override it? No, you just insert a new one with the same name in the Device Driver chain. DOS always searches the chain in order, and uses the first one with the correct name that it finds. It doesn't actually know, or even care, where the "real" one is. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
Ok, sorry, that's what I meant. That you find the chain at the List of Lists, right? Aitor 2011/7/10 Bret Johnson : >> I'm curious, you check the LoL to get the pointers and override it? > > No, you just insert a new one with the same name in the Device Driver chain. > DOS always searches the chain in order, and uses the first one with the > correct name that it finds. It doesn't actually know, or even care, where > the "real" one is. > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard in some computers')
> Ok, sorry, that's what I meant. That you find the chain at the List > of Lists, right? Yes. The first Device Driver header (NUL) is in the LoL. From there, you can follow the chain (a linked list of pointers) as far as you want, and can insert/remove new headers wherever you want. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
Re: [Freedos-user] Unicode (It was 'Problem with USB keyboard insome c omputers')
> Most programs could already be loaded earlier in CONFIG.SYS if they > were adjusted in that way, though some of the DOS structures aren't > available yet in that case. That's one of the big advantages of TSR's, in my opinion. While CONFIG.SYS is being processed, DOS is not yet "all there". As a result, there are certain advanced DOS support functions you can't (or at least shouldn't) try to use, because they may not actually exist yet. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
