= Cdrtools =

cdrecord has ISO-8859-1 characters hard-coded in its messages. Thus, they can't be displayed properly in locales using other character sets. Also, they make some UTF-8 terminal emulators upset. If you have Glibc and the de_DE locale and understand legal consequences of doing that, run the commands below to convert messages to ASCII approximations (e.g., "J<wrong or invalid character>rg Schilling" -> "Joerg Schilling"). Alternatively, apply [http://wiki.linuxfromscratch.org/blfs/attachment/wiki/Cdrtools/cdrtools-2.01-ascii-1.patch?format=raw this patch] that has the same legal consequences.

{{{
for F in cdrecord/cdrecord.c cdrecord/diskid.c cdrecord/sector.c \
    readcd/readcd.c scgcheck/scgcheck.c scgskeleton/skel.c ; do
    LC_ALL=de_DE iconv -f ISO-8859-1 -t US-ASCII//TRANSLIT $F >tmp
    mv -f tmp $F
done
}}}

The comment in cdrecord.c states that, because of GPL requirements, you are not allowed to do that (because these commands modify the copyright notices), but how can a copyright notice containing invalid byte sequences be valid? !RedHat ignores this comment and patches copyright notices.

----

When creating an ISO image with Joliet extensions (for long file names on MS Windows), it is necessary to specify the correct input filename character set with the -input-charset (or, equivalently, -jcharset) option. The character set name passed after this switch must match the output of "locale charmap". A mismatch results in completely wrong characters non-ASCII in the filenames under MS Windows.

Problem 1: unpatched mkisofs accepts only character sets listed in the "mkisofs -input-charset help" output, and UTF-8 is not in the list.
Problem 2: some GUI frontends don't know that this option has to be passed, and don't allow a user to add it at all.

[wiki:CDWritingUtilities Up][[br]]
[wiki:BlfsNotes Top]