[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bf build with lang chooser turned on



In <[🔎] 20000522232951.A15144@transas.com>,
 at "Mon, 22 May 2000 23:29:51 +0400",
 with "Re: bf build with lang chooser turned on",
  Michael Sobolev <mss@transas.com> writes:

Hi.

> On Fri, May 19, 2000 at 11:40:31PM +0200, Marcin Owsiany wrote:
> [ the build with language chooser turned on failed.  let's put the needed stuff
>   into cvs tree ]

> Well, I am not sure that putting those libraries into cvs tree is a very good
> idea.  They are really big.  Language choose is not maintstream thingie.  So a
> person who is going to create her own boot floppies will have to download 800K
> more.  What do you think?  Well, if we are not going to put these libraries
> into boot-floppies package, then the user will have to download the stuff
> herself.  I believe than there is no point (well, almost no point :) to make
> the procedure for cvs and non cvs methods different.

But if this i18n flavor will go into potato (*1), then we must
provide all the source required to build it.

 *1: Adam said: 'Remember, we can continue to do "point releases" of 
Potato boot-floppies even after Potato is released.' so i18n floppy 
has the possibility to go into potato as the post-release version.

So, we have to do one of two:

 A) Create new library package for patched newt and slang, upload
    and imcorporate it into potato as normal package.

 B) Get the patched source codes into boot-floppies, and do not
    get them into potato as normal package.

I prefer plan A) above, because the patched library is only needed
for boot-floppies currently.

If we can not do none of these, then we can not provide the i18n version
of boot-floppies, I think.

> What I am trying to say.  Let's create the file called README.language-chooser
> (or README.i18n or whatever) and refer to the file utilities/bogl/README.bterm
> where all the needed information is given.

I think we can commit the source for libutf8, at least.
libutf8 (http://www.rano.org/tmp/bogl-libutf8.tar.gz) is
just 12811 bytes in compressed tar form, and about 80kbytes
in extracted tree. I think we should commit this into cvs 
at first. How do you think ?

This libutf8 is GPLed, and the README said:
 "When glibc-2.2 is part of Debian, this code will no longer be needed."
so this may only be needed for potato. (Woody may have glibc-2.2, I suppose)

By the way, I tried to check bterm on manually created
root floppy (based on my locally-built ja version, because 
the standard one does not have ioperm support in libc.
Maybe the library reduction related.) 

And "bterm -f /usr/lib/bterm/ucsfonts.bgf -l C.utf8"
can show the characters in 9x18.repertoire-utf8.
In fact, some characters ("Combining Diacritical Marks"
are one of them) are missing, but many charcters are seen.

The font file used as ucsfonts.bgf is converted from 9x18.bdf.

Then I put the merged bgf (from 9x18 and 18x18ja) and
the utf8 converted messages (.po) into extra floppy.
(I use compressed ext2 using ramdisk and loop device
in order to create this extra "font & message" floppy)

And again I did on my custom root floppy:

  export LANG=C.utf8
  mkdir /fonts
  gunzip -c /dev/fd0 |dd > /dev/ram1
  e2fsck /dev/ram1
  mount -r /dev/ram1 /fonts
  bterm -f /fonts/bogl-fonts/ucs-fonts.bgf

This /fonts/bogl-fonts/ucs-fonts.bgf is the merged bgf.
And the bterm can show the Japanese characters in
 18x18ja.repertoire-utf8, I also check some messages
(.po) in /fonts/utf/ (I copied them here from utilities/
dbootstrap/po/utf), and it seems to be OK as far as I can.
(In fact, I do not know much about other language than
english and Japanese. I have learned french in my university,
but it is long ago, more than 10 years) 

Well, next are the patches for newt and slang:

       11117  newt-0.50-5.3-ege1.diff
       23613  slang-1.4.0-ege5.diff

about 35kbytes. But I have problem with the patch for slang.

The source code for newt provided by existing libnewt0 package:

    14299  newt_0.50-7.diff.gz
      604  newt_0.50-7.dsc
    93475  newt_0.50.orig.tar.gz

about 108kbytes. Maybe something can be done to extract the
required code from the source package of newt and use them 
to build the required patched libnewt0-utf8.

(I personally tried to build the local package of libnewt0-utf8
 using the current newt source package. But this requires the
 newer slang than the version in potato, and the functions in 
libutf8, so this is not so easy.)

And, I don't have the source code for slang 1.4.0. I can get 
the source for slang 1.4.1,

    577548 slang-1.4.1.tar.bz2
    607583 slang1.4-doc.tar.bz2

about 578kbytes. And the patch for 1.4.0 provided by Evans
can not be applied to this 1.4.1 clean. There are two ".rej"
files. While there are four (all) ".rej" files when I try to
apply this patch to 1.3.9 (version in potato). So I don't have
the version to use now. And the newt-utf8 requires slang-utf8
when building, I don't have working newt-utf8 now.


Finally, the biggest files come. The ucs font files:

   847774  ucs-fonts-asian.tar.gz
   724492  ucs-fonts.tar.gz

in gzipped-tar form, and about 12Mbytes in extracted source tree.

The really needed ones in these font archives are:

     4120810  18x18ja.bdf (for asian characters)
      764830  9x18.bdf    (others)

I think these font files are the same one which is provided
in XFree86 4.0, and we can use these as DFSG compatible one.

The size of converted bgf (bogl font) files are

      1780170  ucs-fonts.bgf (for all fonts)
	      
      1535528  ucs-fonts-asia.bgf (for asian fonts)
       351365  ucsfonts.bgf       (for others)

so maybe if we use only the ucsfonts.bgf, then the special
root floppy image for i18n can be created manually without
font reduction, as the first trial, I think.

But if we try to build the true i18n floppy includes
the asian font support, then font reduction technology
may be the essential. 

If we can not do the font-reduction, then we have to escape
the problem with other work-around trick. Ffor example, 
supply the extra floppy for fonts file to load them into 
the other ram-disk filesystem, because the root on /dev/ram0 
can not afford to get them. Using this approach, we will use
the same resc/root/drv disks for all LINGUA, and one of several
(maybe two or so) "font and message" disk. Users can switch
the language by replace that "font and message" disk.

Ah, I have not consider this approach thoroughly, but the size
of messages.trm files for all LINUGA may not fit in a single
root floppy disk, so we may need an extra disk anyway.
I have created 17 .trm files in utf8, and the total size of
them are 920479 bytes.


Summary:

If we give up the idea of having utf-8 based i18n language-chooser
version of b-f, then we don't need to do anything.

But if we wish to work for it, then we need (in my opinion):

 - to commit the source of libutf8 as utilities/libutf8 in cvs for b-f
   This is required to use the utf8 on bterm.

 - to commit the source for patched newt, or at least commit the patch
   itself. One can get the source for original newt via the libnewt0
   package.

 - to commit the source for patched slang, or at least commit the patch
   itself. If we can easily backport the patch to 1.3.9, the potato 
   version of slang, then it is more convenient for us. But if this
   requires very hard work, then we should simply use the newer one,
   I think. 

   The best for us is that the upstream of slang and newt incorporates 
   the support for utf8 into their own code, so that we can safely use
   that feature in woody or later. But for potato (even as the point 
   release after the release of potato) we have to provide the working 
   code by ourself.

 - Well, last one. The ucs font files.
   I prefer to have the gzipped bdf for 9x18 and 18x18ja in utf8.
   The sizes of .bdf.gz are about 614kbytes and 64kbytes,
   and this enables the usage of utf-8 on bterm.

   If we can create the new package of .bgf for these fonts
   (maybe "boglfonts-utf8" resides in /usr/share/fonts/utf8-bgf/), 
   and upload and get them into the potato, then it will be more 
   handy. But this needs approval from our Release Manager.

Regards.

P.S.

C.po can not be converted into utf-8 with 
 "Content-Type: text/plain; charset=CHARSET\n"
so we should modify Makefile to produce C.po
with something
 "Content-Type: text/plain; charset=ascii\n"
or so.

   $ LANG=C make utf/C.trm
   iconv -f "`grep '^"Content-Type:' C.po | sed -e 's/^.*charset=\\(.*\\)\\\\n.*/\\1/'`" -t utf-8 < C.po > utf/C.po
   iconv: conversion from `CHARSET' to `utf-8' not supported
   make: *** [utf/C.po] Error 1
   rm utf/C.po

C.po is built with

    C.po: $(PACKAGE).pot genc.awk
           gawk -f genc.awk < $(PACKAGE).pot > $@

in Makefile, and I think it is enough to add a sigle sed command
in order to replace 'charset=CHARSET' with 'charset=ascii'.

-- 
  Taketoshi Sano: <sano@debian.org>,<sano@debian.or.jp>,<kgh12351@nifty.ne.jp>



Reply to: