When using Hebrew (http://sourceforge.net/tracker/?func=detail&aid=3440038&group_id=5109&atid=105109) I see no difference whatsoever between MINDED and MINED -E=CP862
This is even though kpdos.htm states:
(13) FreeDOS does not handle bidi scripts natively. A proper bidi text editor
is required; tested with Mined only. Usage: "MINED -E=CPxxx", typed in
uppercase (xxx=856 won't work on Mined).
Can you please test it again?
Mined's author himself (Thomas Wolff) has no idea where you came up that -E enabled bidi support.
It's -u that enabled bidi support. Mined detects the codepage by itself so there's no need to use -E.
So please fix this issue by editing the aforementioned page to just state "MINED -u".
Actually, even "-u" is not needed because Mined auto-enables bidi support.
So running just Mined.exe by itself is enough. Please fix the documentation accordingly.
There were many changes on Mined since 2012, see: https://mined.github.io/
If necessary, could you report it there?
Could you please tell us if this thread can be closed? Thx.
Mined didn't need to change anything, it still auto detects bidi just like it always did (confirmed by re-testing its latest version just now).
it's FreeDOS' documentation that still needs fixing after all these years (especially since keyb never got any update since).
So it (I guess here) should be fixed to just:
Last edit: lwc 2024-08-14
As I am only the translator of the help (actual version kpdos 3.1) see my other website: https://www.bootablecd.de/FreeDOS-Internet-version/help110/en/hhstndrd/other/kpdos.htm
I will have to ask if this comment is correct (I think it is, but I have to ask). If yes, I will try to correct it.
Only a question for security: What do you mean with "siht"? Is it a typo? Do you mean "sight"?
Yes, it's correct. But I've rephrased the desired comment to make it clearer. I've meant a word like this will get reversed, thus siht (which is the reverse of the word this).
With words like siht now you understand why bidi is so important, as everything gets reversed without it...I think it's safe to assume if keyb's developer used a language that does this he/she wouldn't have thought to release keyb without bidi support.
Last edit: lwc 2024-08-14
Hello:
So the problem is with this sentence in kpidos.htm?
(13) FreeDOS does not handle bidi scripts natively. A proper bidi text
editor
is required; tested with Mined only. Usage: "MINED -E=CPxxx", typed in
uppercase (xxx=856 won't work on Mined).
There are 4 sentences there:
1-The fact that FreeDOS does not support right-to-left languages is ok. It
would be a major endeavour to support it, affecting mainly the CON device
driver, but also any TUI/GUI application (such as EDIT or HELP), i.e.
anything that displays information outside a CON.
2- I don't know if Henrique is online to clarify why an editor is required,
I assume he meant it is required for it to be properly tested, and that he
used MINED. According to the comment, I suppose that Henrique would test
both DISPLAY and KEYB together.
3- I don't know the method used by MINED to determine the codepage. If it
uses int21h/AX=6601h, it will probably require -E to test, as most folks
don't use NLSFUNC/CHCP, and the system codepage may not be aligned with the
one you configure in DISPLAY, and thus the comment is ok.
If it calls int2Fh/AD02h (call DISPLAY), it has been pointed out that the
comment would be superfluous: you don't need the -E (but I guess it doesn't
harm either).
4- If xxx=856 won't work on MINED: I don't know if this is true, but anyway
would be a bug in MINED, not in FreeDOS.
So maybe remove 2 and 4 in kpidos.htm and the bug can be closed?
(13) FreeDOS does not handle bidi scripts natively. Tested with Mined only.
Usage: "MINED -E=CPxxx", typed in uppercase.
Or even furthermore, why comment here how MINED works, if that would belong
to the MINED documentation?
(13) FreeDOS does not handle bidi scripts natively. Tested with Mined only.
Thanks,
Aitor
On Wed, 14 Aug 2024 at 23:09, lwc l-w-c@users.sourceforge.net wrote:
Related
Bugs: #87
From my side there are some questions too:
a) You wrote "script"? Does this NOT affect all texts, e.g. documents etc?
b) "(i.e. this gets reversed to siht)" I think this is a bad to understand example. I didn't at the beginning. Something like:
To be able to read:
"This is a text."
in bidi (from right to left) you have to type:
".txet a si sihT"
in standard DOS editors. As this is almost unduable you need special editors like
mined? What happens if you type: ".txet a si sihT" into a standard editor with your codepage?
If I understand correct this is readable for you but of course very hard to write.
c) Just to be sure: Mined does not need the FD codepage as they are built in? But you need an FD codepage 856 (or another one marked with (13) ) if you want to read the text with another editor, e.g. "edit"?
d) If c) is correct: Are the characters shown correct with a standard editorif you read from right to left?
Sorry, but I am not very familiar with reading from right to left.
Hello,
On Thu, 15 Aug 2024 at 15:05, fritz.mueller willy-billy@users.sourceforge.net wrote:
If you output strings to screen, either you write to DOS' CON (and thus,
CON should deal with this), or directly use BIOS/hardware, and in that
case, it is up to you to deal with it.
Related
Bugs: #87
I feel this is getting much more complicated than it is:
something like this
and it will becomesiht ekil gnihtemos
something like this
than it will stay like that without getting reversedMeaning:
So how about rewriting the comment into:
Last edit: lwc 2024-08-16
What does keyb have to do with right-to-left?
On Fri, 16 Aug 2024 at 13:33, lwc l-w-c@users.sourceforge.net wrote:
Related
Bugs: #87
if keyb turns your keyboard into a right-to-left language but have you type it left-to-right, it means you have to type everything reversed, so you can't really work like that.
Obviously the person who wrote the original comment felt so too, otherwise they wouldn't have bothered to mention it doesn't support bidi (meaning they knew right-to-left users will ask about it).
Last edit: lwc 2024-08-16
I am sorry but KEYB doesn't do such things as to "turn into a
right-to-left" language.
Supporting right-to-left languages would be a feature request (for kernel
at least).
Nevertheless, the user that opened the bug is not complaining about
right-to-left languages, (it was Henrique who wrote that bidi is not
supported, and he is right), (s)he says to retest MINED (but it is not
mentioned why?), so should be assigned to MINED.
Aitor
On Fri, 16 Aug 2024 at 20:02, lwc l-w-c@users.sourceforge.net wrote:
Related
Bugs: #87
I just meant keyb lets you type letters of right-to-left languages, but due to the lack of bidi support it actually types them left-to-right.
Again, that person just meant a third party tool like Mined is needed to actually type right-to-left.
I suggest just use "So how about rewriting the comment into:".
Last edit: lwc 2024-08-17
What about this text, it is not country specific, and says everything that people that use bidi need. Other people will be not interested in it. More information about mined is the job of mined help.
I think this enough.
(13) FreeDOS supports these codepages, but it does NOT support bidi, means, it cannot write from right to left as it is done in parts of the world ("Something like this" will have to be typed "siht ekil gnihtemoS" in FreeDOS.
For proper bidi support, a third party program is required, for example the editor "Mined".
means,
should bemeaning
.Therefore, I propose:
Just for info:
It is becoming more complicated as FDT2408 says it supports is keyboard, but I noticed that it uses mkeyb which requires the right CTRL (Strg) button - and virtualbox uses this for other purposes. So I will have to run tests on bare metal to see what really happens. This may last a while.
Where do you see that? The changelog mentions both (and also xkeyb), but calls mkeyb "unstable".
Besides, what does it have to do with wrong documentation about Mined?
Unless you claim the "unstable" mkeyb has bidi support which I seriously doubt.
Also note it's older than keyb (but at least not as old as xkeyb).
mkeyb is stable, I know that there are three different keyboards. But the latest version only installs "mkeyb is" without any other country related settings. The result was that virtualbox was unable to support right CTRL button and mined did not work with bidi.
So I simply want to test all combinations with the different keyboards, codepages and country settings to be sure which combinaions really work. And this will last a while.
I have no plans to continue this discussion until this is done.
OK,
after a few minutes of work here is a summary now:
We talk about the codepages 862 (Isr), 856 (Isr) and 864 (Egypt and others) as well as about xkeyb, mkeyb and keyb and config.sys (here: country and country.sys).
Country.sys does not support 864 and 856, there is a short message while booting.
see also https://bootablecd.de/FreeDOS-Internet-version/help110/en/hhstndrd/cnfigsys/country.htm, 856 is not mentioned here and 862 seems to work. But this setting is not really needed. If you think you need it you can try "localcfg". See: https://bootablecd.de/FreeDOS-Internet-version/help110/en/hhstndrd/util/localcfg.htm - it has a small bug but this can be fixed, see examples there.
a) xkeyb has no key file for Israel and Egypt. So it is not usable for your countries.
b) mkeyb ONLY has the option /HE, sometimes you also need /e to work (I recommend to set it). It requires CP862 from EGA17.cpx OR CP856 (see below) from EGA18.cpx to be set before. I did not test CP856.
It changes from abc to HE by clicking right CTRL button. This is bad in VirtualBox as CTRL is needed for coming out of the DOS window. But you can run it in a real machine or another virtual machine.
Mkeyb works FINE in COMMAND LINE and in EDIT with HE (writes from left to right) but I was UNABLE to activate HE by RIGHT CTRL in mined. As it works in command line and in edit I am sure that there is a bug in mined.
I tested mkeyb 0.40 too - and it behaves the same way (except it uses other keys to switch from abc to HE). But both versions did not work in mined.
Means: I was unable to use mkeyb for mined.
c) keyb:
862, keybrd3.sys, EGA17, uses ALT+RIGHT SHIFT ONCE for writing in HE, ALT+LEFT SHIFT for writing in european chars in command line.
In edit it requires ALT+right shift (or ALT+left shift) TWICE! And writes in HE (Reason: first ALT-SHIFT opens edit menu, second changes to HE)
In mined it requires ALT+right shift (or ALT+left shift) ONCE! Then it writes from right to left automatically. Means: It works fine.
856, keybrd3.sys, EGA18, uses ALT+right shift ONCE for writing in HE, ALT+left shift for writing european chars in command line.
In edit it requires ALT+right shift (or ALT+left shift) TWICE! And writes in HE! (Reason: first ALT-SHIFT opens edit menu, second changes to HE)
In mined it requires ALT+right shift (or ALT+left shift) ONCE. BUT IT DOES NOT SHOW HE CHARACTERS but absolutely different AND WRITES NOT FROM RIGHT TO LEFT!
Means: I was unable to create HE text. I think this is a bug in mined.
So you can think about how to correct this in kpdos.htm
864, keybrd4.sys, EGA17, arabic, command for keyboard is as follows:
keyb ar,864,C:\freedos\bin\keybrd4.sys /ID:470
uses ALT+right shift ONCE for writing in Egypt etc, ALT+left shift for writing european chars in command line.
In edit it requires ALT+right shift (or ALT+left shift) TWICE and writes in Egypt etc! (Reason: first ALT-SHIFT opens edit menu, second changes to AR)
In mined it requires ALT+right shift (or ALT+left shift) ONCE! Then it writes from right to left automatically.
Result:
At least 4 versions should work, but only 2 do so. Please check it, you only have to modify fdauto.bat. So I would say that it makes sense to ask the programmer of mined for fixing these problems before worrying about the text. Can you report this to the programmer?
Or do I have to do this too?
Nice research! Wish FreeDOS just supported bidi natively, but in any case:
That's for point #2, not #1. But yeah, that's the address I have. Then again, it might be someone from FreeDOS and not Mined itself that put this possibly outdated address. The project itself is from 2022 and links to an obsolete Mined tracker.