Syslinux - Mar 2013 - Allowed code pages and encodings to write f0.txt through f1.txt?

Hi there.

Slackware's installer, that I am internationalizing, makes use of ISOLINUX.

I want to give instructions to users in other languages than US English, e.g.
which code to type
to see installation messages in their native language.

So my question are:

(1) Which character encodings can be used in message.txt and f1.txt through
f1O.txt?
(2) Is UTF-8 allowed?
(3) I'm guessing that information in /codebase could be useful to answer my
questions but
     don't know how I could use it. Could you please shed some light on this
directory's
     content purpose and usage? (I'm not a programmer).

TIA for your answers

Didier

On Mar 26, 2013 7:44 PM, "Didier Spaier" <didier.spaier at
epsm.fr> wrote:
>
> Hi there.
>
> Slackware's installer, that I am internationalizing, makes use of
ISOLINUX.
>
> I want to give instructions to users in other languages than US English,
e.g. which code to type
> to see installation messages in their native language.
>
> So my question are:
>
> (1) Which character encodings can be used in message.txt and f1.txt
through f1O.txt?

Assuming vesamenu.c32 and gfxboot.c32 are not in the mix, BIOS native
codepage only.  You can use whatever 8-bit characters you want but the
user's PC's BIOS does the codepage selection.

Some past Ubuntu ISOs did a fancy job with gfxboot.c32.
> (2) Is UTF-8 allowed?
Same.
> (3) I'm guessing that information in /codebase could be useful to
answer
my questions but
>     don't know how I could use it. Could you please shed some light on
this directory's
>     content purpose and usage? (I'm not a programmer).
Assuming you mean codepage/, that's for FAT* long file name translation
only, translating a 16-bit character to an 8-bit.
> TIA for your answers
>
> Didier
--Gene

On 03/26/2013 04:02 PM, Didier Spaier wrote:
> Hi there.
> 
> Slackware's installer, that I am internationalizing, makes use of
ISOLINUX.
> 
> I want to give instructions to users in other languages than US English,
> e.g. which code to type
> to see installation messages in their native language.
> 
> So my question are:
> 
> (1) Which character encodings can be used in message.txt and f1.txt
> through f1O.txt?
> (2) Is UTF-8 allowed?
> (3) I'm guessing that information in /codebase could be useful to
answer
> my questions but
>     don't know how I could use it. Could you please shed some light on
> this directory's
>     content purpose and usage? (I'm not a programmer).
> 
Now in Syslinux 5 we probably have enough infrastructure to do UTF-8
right.  This is 2013, UTF-8 everywhere would make a lot of sense.  We
already have to carry Unicode conversion tables to deal with VFAT.

	-hpa

> (1) Which character encodings can be used in message.txt and f1.txt through
f1O.txt?
 
The default in the BIOS, mainly Code Page 437
 http://en.wikipedia.org/wiki/Code_page_437 

This code covers many (most) of the characters used in Latin-derived 
scripts (alphabets), Western European countries.

In theory, in the cfg file you could potentially add a FONT directive 
and a .psf font file (see the official Syslinux package, 
.doc/syslinux.txt), but this method is very rarely used.
 
> (2) Is UTF-8 allowed?
 
Not yet.

Hi,
> Implementing Rock Ridge and/or Joliet for ISO 9660 would be nice, too.
That would be in my sandbox ... if i only had a clue of syslinux.

Nevertheless i tried to find the source and ended up at
 
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/core/fs/iso9660/iso9660.c
Is that the current ISO 9660 code ?

If so, then Rock Ridge would affect function iso_find_entry().
It would need a SUSP decoder loop which looks for NM entries and
combines them to candidates for e.g. strcmp().
There would be the need for a second data block buffer into which
the target blocks of CE entries will be read.

A similar change would be needed in function iso_readdir().
It seems worthwhile to create a common Rock Ridge name retriever
function.

Function iso_convert_name() would not be needed for Rock Ridge names.

The existence of Rock Ridge would be announced by an ER entry
in the root directory record. But one could as well always look
whether the System Use field of an ISO 9660 directory record
contains SUSP and RRIP entries.


The existence of Joliet in an ISO image is announced by a Joliet
volume descriptor. The filesystem reader should then take the
root directory record from the Joliet descriptor rather than from
the Primary Volume Descriptor.
Functions iso_compar_name() and iso_convert_name() would have to
deal with UCS-2 strings rather than byte strings. Elsewise, Joliet
and ECMA-119 have the same structure.

Interpretation of Joliet and Rock Ridge is mutually exclusive.
One would have to decide early, which one to use, if both are
present.


References:
ECMA-119 aka ISO 9660
  http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf
SUSP 1.12 (entries CE , PD , SP , ST , ER , ES)
  ftp://ftp.ymi.com/pub/rockridge/susp112.ps
RRIP 1.12 (entries PX , PN , SL , NM , CL , PL , RE , TF , SF , obsolete: RR)
  ftp://ftp.ymi.com/pub/rockridge/rrip112.ps
Joliet:
  http://www.buildorbuy.org/pdf/joliet.pdf


Have a nice day :)

Thomas

On 03/27/2013 01:03 PM, Thomas Schmitt wrote:
> Hi,
> 
>> Implementing Rock Ridge and/or Joliet for ISO 9660 would be nice, too.
> 
> That would be in my sandbox ... if i only had a clue of syslinux.
> 
> Nevertheless i tried to find the source and ended up at
>  
http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/core/fs/iso9660/iso9660.c
> Is that the current ISO 9660 code ?
> 
Yes.
> If so, then Rock Ridge would affect function iso_find_entry().
> It would need a SUSP decoder loop which looks for NM entries and
> combines them to candidates for e.g. strcmp().
> There would be the need for a second data block buffer into which
> the target blocks of CE entries will be read.
> 
> A similar change would be needed in function iso_readdir().
> It seems worthwhile to create a common Rock Ridge name retriever
> function.
> 
> Function iso_convert_name() would not be needed for Rock Ridge names.
> 
> The existence of Rock Ridge would be announced by an ER entry
> in the root directory record. But one could as well always look
> whether the System Use field of an ISO 9660 directory record
> contains SUSP and RRIP entries.
Yes, that is almost certainly easier; it becomes a local change to the
directory parser.
> The existence of Joliet in an ISO image is announced by a Joliet
> volume descriptor. The filesystem reader should then take the
> root directory record from the Joliet descriptor rather than from
> the Primary Volume Descriptor.
> Functions iso_compar_name() and iso_convert_name() would have to
> deal with UCS-2 strings rather than byte strings. Elsewise, Joliet
> and ECMA-119 have the same structure.
> 
> Interpretation of Joliet and Rock Ridge is mutually exclusive.
> One would have to decide early, which one to use, if both are
> present.
Quite correct.  We would either go the Linux route of Rock Ridge >
Joliet > plain 9660 or be lazy and just do one or the other.  Doing
Joliet > Rock Ridge makes no sense whatsoever.

	-hpa