Mirsad Todorovac wrote:
You probably remember me having problems with iso-8859-2 (Latin 2) charset when translating GNU Pascal documentation to Croatian.
If you are doing something similar to some other languages which require 8-bit (above first 127) characters, I've noticed some problems with the way GNU 'info' displays menu items that contain them - GNU 'info' shifts the "hotspots" of every menu item bellow first such character by one line, so you have to select a line bellow an item to select that item.
I'm not to proud with the way I coped with this, since I had to leave those menu items in English, and translate them on the right side in description part (where 8-bit chars are treated correctly).
Any better ideas?
Well, GNU info is only one info reader. There are many others (Emacs, RHIDE, PENG, ...). A documentation file should not be messed because of the bugs in one program, I think. So my suggestion is: Report the bug to the info maintainers, and ignore it otherwise. People wanting to read the documentation will have to get an updated info (once the bug is fixed), or use another reader, or just live with it (it's not a fatal bug after all).
'makeinfo' inserts spurious line-breaks when 8-bit chars and DOS-style line-breaks are present. After figuring out to erase CTRL-M's from the file, 'makeinfo' output began to look as expected.
The problematic was @table @asis ... @end @table section (others didn't show problems with or without CRTL-Ms ...
That's another issue since I don't think makeinfo was designed to (or should) accept those CR characters for any reason. So just make sure to remove them before running makeinfo (easy to automatize with a little script using sed or tr).
I don't know whether GNU 'makeinfo' renders tables correctly under MS DOS enviroment (in this case my solution would break there)?????
I guess so, since many people are using info files under DJGPP. Also GCC/GPC have to problem with LF delimited files under DJGPP. I think the reason is in either libc or the "Dos extender" -- when files are opened as text, it converts CR/LF to LF, but leaves plain LF unchanged (what else should it do, anyway? ;-). That's unlike most Dos compilers (Borland etc.) where the libraries don't do any conversion at all and the program code is left do deal with line breaks, so it depends on the program whether or not it accepts plain LF (e.g., the Borland Pascal IDE can read them since version 6.0, but not in earlier versions).
Frank