indic-computing-devel Mailing List for The Indic-Computing Project (Page 2)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> Pls suggest workarounds.

What will the path names for these 'control' files look like
when in the repository?  I will turn off $Id$ checking for these.

Regards,
Koshy
<jk...@fr...>

Sorry, I goofed up the first send....

Thanks,

Cherry

--- Cherry George Mathew <ber...@ya...>
wrote:
> From Cherry George Mathew Mon Jul 26 10:13:15 2004
> Received: from [220.226.9.232] by
> web52006.mail.yahoo.com via HTTP; Mon, 26 Jul 2004
> 10:13:15 PDT
> Date: Mon, 26 Jul 2004 10:13:15 -0700 (PDT)
> From: Cherry George Mathew <ber...@ya...>
> Subject: $Id$ header blues
> To: ind...@ya...
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Length: 648
> 
> Hi Koshy,
> 
> I've got a small problem with committing debian
> 'control' files to the source tree.
> 
> debian 'control' files have a rigid format, and
> don't
> have provision for adding comments. That means that
> inline versioning can't happen for these files.
> 
> Any suggestions ?
> 
> CVSROOT/commitcheck.py refuses to take commits
> without
> $Id headers. I could import the new sources, but
> that
> would defeat the purpose............. also further
> commits would crash land.
> 
> Pls suggest workarounds.
> 
> Thanks,
> 
> Cherry
> 
> 
> 
> 
> 
> 
> 
> 		
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail 
> 

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

--- Joseph Koshy <jk...@Fr...> wrote:
[...]
> Do you really need a directory in CVS named
> bsdmake-1.0.orig?
[...]
> Putting version numbers into directory names may not
> be a good idea
> since you are not going to be at "1.0" for long.
> 

The version number is for the debian package, not the
upstream version. The upstream version is named (
release tagged ) exactly the same as the freebsd
release engineering tag name. 

 cvs log Makefile|grep -A2 symbolic

 or so should tell you what I'm carping about.

> With CVS you normally use a vendor branch for
> tracking external 
[...]
> lot of effort.  So this '.orig'/non-'.orig' layout
> appears to be working
> against the way we normally use CVS, unless I've
> missed something.
> 

I think you missed the point. The non-'.orig' stuff
contains all the debianized info, including but not
limited to:

a directory called debian/ with all the package info,
altered Makefiles etc. conforming to the debian file
heirarchy standards ( which are quite different from
the BSDs, no meddling with /usr/local, for example )
etc. So as the 'package maintainer', you're right
about the fact that I would have to painfully sort out
all the stuff in an upgraded version. The nice thing
about this is that I might be able to push this
package into the debian repository, and gleefully
shirk my responsibility in favour of debian
developers' efforts. At that point, we could end of
life the vendor tree here.

> 
> Oops.
> 
> With SF.Net CVS you do not have the ability to go
[...]
> project developers.
> 

Uh oh.... I'm sorry about that one.....

The workaround is to do what the NetBSD folks have
been doing ( why am I behaving like one already :-) ).

use:

cvs update -dP while updating the sources.

> One course of action would be to file a support
> request asking 
> SF.net's CVS meisters to remove the botched import
> in its entirety
> and then start afresh.

Will do. Thanks for the tip.

Best,

Cherry.

__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail

cgm> debian/bsdmake/
cgm> debian/bsdmake/bsdmake-1.0.orig/*

Do you really need a directory in CVS named bsdmake-1.0.orig?

BSD make keeps evolving and I presume you intend to be tracking this.
Putting version numbers into directory names may not be a good idea
since you are not going to be at "1.0" for long.

With CVS you normally use a vendor branch for tracking external 
sources and keep your local changes on -HEAD.  If you do not do it this
way, much of CVS's automated merging won't work, at least not without a
lot of effort.  So this '.orig'/non-'.orig' layout appears to be working
against the way we normally use CVS, unless I've missed something.

cgm> debian ) would have targets to automate everything
cgm> from compiling the package

Thats cool.

cgm> 2) I've screwed up the directory positions for peps.

cgm> CVS gurus HEEEEEELPPPPPP!!!!!

Oops.

With SF.Net CVS you do not have the ability to go and directly repair 
damage to the CVS repository.  The repository itself is off-bounds to
project developers.

One course of action would be to file a support request asking 
SF.net's CVS meisters to remove the botched import in its entirety
and then start afresh.

Regards,
Koshy
<jk...@fr...>

Hi All,

I'm about to make myself look like the biggest idiot
who ever used CVS. So brace yourself.

Here is what I've been trying to do.

To make the following directory structure rooted at:

src/package-definitions/doc-toolchain:

debian/
debian/bsdmake/
debian/bsdmake/bsdmake-1.0.orig/*
debian/bsdmake/bsdmake-1.0/*
debian/peps/
debian/peps/peps-1.0.orig/*
debian/peps/peps-1.0/*

All subdirectories with *.orig would have upstream
sources. The subdirectories without .orig extensions
would be "debianized" modifications.

The idea is to run:

make deb-src from , say within debian/bsdmake, and to
obtain a freshly laid out deb-src directory as
follows:

debian/bsdmake/
debian/bsdmake/bsdmake-1.0_1.diff.gz
debian/bsdmake/bsdmake-1.0_1.dsc
debian/bsdmake/bsdmake-1.0_1.orig.tar.gz
debian/bsdmake/bsdmake-1.0/*

From here, it would be a simple matter to build the
.deb files, make them into apt-get able trees etc.

All this would be automated with repective Makefiles,
in the above example:

debian/bsdmake/Makefile ( GNU Makefile, cause we're on
debian ) would have targets to automate everything
from compiling the package to installing the apt-get
deb archive via apt-get install ......

Now here's what I've done and botched up. CVS gurus
HEEEEEELPPPPPP!!!!!

I did a cvs import src/..../debian/bsdmake which was
all very nice and dandy except for two problems:

1) The head revision somehow got screwed to 1.1.1.1,
which pisses me off really badly, because the rest of
the tree is clean with 1.X revisions, and I've
unwittingly created a branch.

My idea was to pullup these 1.1.1.X revisions into the
1.X revisions on the Trunk, so that if a new version
of, say bsdmake were to be integrated on the Vendor
Branch, the new version would be 1.1.1.2, and the
pulled up version on the Trunk would be 1.2

How can I do the initial pullup. ie; pullup from
branch 1.1.1.1 to Main Trunk 1.1

Or, have I screwed up ?

2) I've screwed up the directory positions for peps.

peps should have been in:

debian/peps/peps-1.0.orig/*

Instead, I got it screwed up with a typo. Its now in:

debian/peps/*

Hmmm..... I'm sniffing already..... 

Can someone help with this ? I'd love to see the tree
back with 1.X revisions until we decide on TAG names.
I can see a JOSEPH_KOSHY tag already.

I would love to make a private CGM tag, and get the
branch on it, so as to keep other folks from getting
messed up with my commits,  but don't want to touch
anything until the level of damage has been assessed.

Thanks,

Cherry.

__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

Hi,

Localization Newsletter Issue 5, 15th July 2004 is out.
Newsbits: 
* Newsletter in Hindi -
http://indlinux.org/wiki/index.php/HindiNewsletter1
* Discussions in Unicode Indic list - Bengali Khanda-Ta issue, Zero
width joiner for indic
* TSCII - unicode conversion specs

TeamWatch featuring Malayalam localization team.

Read full issue at http://www.indlinux.org/nl/issue5.html

Any feedback on newsletter welcome at <feedback at indlinux dot org>

Regards,
Karunakar

-- 
They can, because they think they can - Anon

--------------------------------------------
* Blog: http://blogs.randomink.org/blog/10 *
* Work: http://www.indlinux.org            *
--------------------------------------------

FYI
--------------------------------------

INVITATION FOR SESSION OR PANEL SUBMISSION
==========================================
Usability and Internationalization Conference, affiliated with 11th
International Conference on Human-Computer Interaction (HCII 2005) July
22-27, 2005 Las Vegas, USA
http://www.hci-international.org

On behalf of the Usability and Internationalization Conference Program
Committee, I would like to invite you to participate in the Usability
and Internationalization Conference in association with HCII 2005, which
will be held in Las Vegas, NV, USA, July 22-27, 2005.

As industries expand into global markets, designers and developers are
becoming more concerned with the needs of culturally diversified target
users. This makes internationalization and localization one of the key
concerns in their minds, and gives a new twist on how we approach
usability globally.

Join experts from around the world to understand the impact of
internationalization on user interface design, share experiences in
designing
for global markets, and understand the future trends in
internationalization. This technical conference will explore the
opportunities created
by the latest
advances in HCI and how to leverage them for global users, as well as
potential pitfalls to be aware of, and problem areas that need further
research. There will also be demonstrations of best practices for
designing applications that can accommodate any language. Attendees benefit
from the wide
range of basic to advanced topics and the opportunities for dialog and
idea-exchange with experts in the field. The conference features
tutorials, lectures, and panel discussions that provide coverage of
standards, best practices, and recent advances in the internationalization
and
usability of user
interf! aces for software applications and the Internet.

I would like to invite you to submit a paper, or organize a session
that either includes 7 paper presentations or a panel session. Topics
include, but are not limited to:

- Cross-cultural design
- Internationalization
- Localization
- International standards
- Globalization process
- Translation
- Technical documentation
- International formatting
- Case studies
- Languages
- Culture studies
- International usability evaluation
- International ethnographic studies

Please let me know by ASAP if you are interested in submitting a paper
or organizing a session with the information requested below.

If you would like to present a paper, please send me the author(s)
affiliation(s), title of your paper and a brief abstract.

If you would like to organize a session:
1) session title that you will be chairing,
2) name and affiliation of the session chair,
3) a list of each of the 7 presenters including their names,
affiliation,
titles and brief abstracts of their papers.

Thank you for your participation in making HCII2005 and affiliated
conferences successful.

Best regards,

Nuray

Dr. Nuray Aykin
Usability and Internationalization Conference Chair
na...@at...
----------------------------------

Regards,
Abhijit

FYI:
---------------------------------

We need a speaker for the Thurs, 7/15/04 IMUG Meeting at Apple HQ in
Cupertino, or for other months this year. See http://www.imug.org

Any topic, even vaguely related to multilingual issues will be
welcomed.

This is a great opportunity to get your company, message, idea, or
product across to a group with over 400 globalization and
multilingual professionals in Silicon Valley and world wide.

Our meetings are always well attended by a cross spectrum of industry
professionals in a conducive setting at our kind sponsor's location,
Apple HQ in Cupertino, CA.

If you would like to present at this next meeting on 6/17 (or another
one) or know of someone who might be appropriate, contact Jim Turley
mailto:jturley_at_xai_dot_com

or Roger Sherman at mailto:imu...@ya...

Jim Turley, XAI

--
XA International                        20205 Saratoga Vista Ct
Contract Programming Agency             Saratoga, CA 95070
International Software Engineering      mailto:in...@xa...
http://www.xai.com
+1 408 741 5577 Voice                    +1 877 895-0979 FAX
---------------------------------

Regards,
Abhijit

Dear Sasikumar,
May I request you to let us have some idea of what has been done so far 
and what is being planned.
Some of us have been in the job for years and are aware of NCST's 
activities too.
Of late the impression is that there are no developments at NCST. It is 
heartening to note that your efforts are going on, and it  seem to 
suggest that there is some activity.May we all know what kind. Are these 
activities put on the site. Any meetings have been held which, obviously 
, I don't seem to know.
I appreciate your emphasis on tool development for localisation rather 
than actual localisation as many of us seem to be emphasising so far. It 
woyuld be nice to know at least broadly , which areas have been 
identified by your initiative for tool development.
I would also like to know who all are working in this area.
I am sure many others in indic language computing would like to know 
this. They may also expect me to know more as my association with C-DAC 
is expected to materialise by many on this matter. Hence I am CCing this 
to them.
I will certainly fill the form you have sent but my info is already on 
our website www.indictrans.org

jitendra

 M Sasikumar wrote:

>Hi,
>
>As mentioned in the initial announcement, with the help of IOSN, we
>are aiming to create a toolkit which explains the process and the required
>resources as well as providing a compilation of software tools which can
>be used to ease the process.  The approach is to compile the various
>scattered sources of information and present them in a coherent form
>for new users to pick up momentum fast.
>
>We are grateful to all of you for your interest in the list. To start the
>process, here is a small questionnaire to formally gather information
>on your relative areas of expertise within localisation, and to gauge
>the availability of relevant information that we can borrow/use.
>
>+++ Your Name:
>
>+++ Are you involved directly in any localisation work? If no, you may skip to
>*** below in the questionnaire.
>
>+++ Please specify the language(s) you are working on.
>
>+++ URL on which we can find more information on the projects you are
>involved in:
>
>+++ What software(s) have you (or your team) already localised? Please
>include which version and any other relevant detail.
>
>+++ Briefly describe the approach taken for localisation
>
>***
>+++ Do you have or know-of any documentation which will be useful for
>localisation efforts? This may include material on fonts/encoding/how-to
>guides/documented experiences/etc. If so, please list.
>
>Note: This is a first level survey, and we will circulate back the
>information collected in the process. We will next pick up specific
>software and then get into more detail.
>
>Thank you for your time, patience and help.
>
>- Sasi
>
>  
>

Also available at:
http://indlinux.org/newsletter/4.html

!!Localization Newsletter Issue 4, Vol 1 (01 July 2004)

!Editor speak

The Indic Localization Newsletter is now four issues old. One of the
enduring themes of this effort has been a greater interaction with the
community and an increased amount of collaboration. Collaboration is
what we believe is the enduring driving force of Free/Libre Open Source
Software. L10n teams collaborate, community and industry collaborate,
communities-industry-government talk to get in implementations of work
done. The operative word here is 'implementation'.

The L10n efforts across the country are mature and at a stage where the
Project Roadmap is well laid out. We have had a number of LiveCDs being
conceived. The next step would be to take it towards a logical
conclusion. L10n efforts are citizen-centric and deployment oriented.
Thus we should take a good long look at domain-centric implementation.
Identify the vertical domains and map out application specific areas
where L10n can be immediately put into action. We need to do this
perhaps in the form of some loosely structured consortia where the
Government and the Industry are also the stakeholders.

The era of LiveCD is over - long live the LiveCD.

----
!News Bits

!News from the Unicode consortium
!Common Locale Data Repository moves to Unicode
The Unicode) Consortium has announced  the release of new versions of
the Common Locale Data Repository (CLDR 1.1) and the Locale Data Markup
Language specification (LDML 1.1), providing key building blocks for
software to support the world's languages. This new release  contains
data for 247 locales, covering 78 languages and 118 countries. There are
also 36 draft locales in the process of being developed, covering an
additional 17 languages and 7 countries.
For more information visit CLDR homepage at http://www.unicode.org/cldr

!Unicode Consortium to decide on changes to Bengali encoding proposals
The Unicode consortium  will be meeting this week,  and among the long
list on the agenda is the issue of allotting a separate code point for
the Bengali Khanda-ta.

Meanwhile,  it has  been  pointed out  that  even if  the proposal  is
accepted,  implementing it  will take  at  least two  years, and  till
then, the  computing community needs to  arrive at a  consensus on how
to encode the khanda-ta. The combinations under discussion are :-
(ta, virama, zwj)
(ta, virama, zwj, zwnj)

The issue  is very sensitive for  the Bangla community,  who, like all
people, hold their dear language close to their hearts. Discussions on
the issue has raised much heat and smoke, that Saraswati* (the mailing
list administrator for <indic at unicode dot org> mailing list) has put
the list on moderation.
(*) Before  you jump into any  conclusion, Saraswati is the  name of a
machine, and not a person.

!Adding a new Indic Language - Tulu
There has been some loud thinking by  Dr. U. B. Pavanaja in one of the
Unicode forums, that Tulu, one of the ancient languages spoken mostly on
the  South-West coast of the  Indian peninsula, should  find a place in
the  Unicode standard.  Raghavendra Bhat, a  Tulu speaker  and free
software advocate, has supported the  proposal, and moves are afoot to
gather  more information  to put  forward a  concrete proposal  to the
Unicode consortium.

Interested  people  should  get  in  touch either  with  Dr.  Pavanaja
<pavanaja at vishvakannada dot com> or Raghavendra Bhat, <ragu at vsnl
dot com>.

!Two new GTK Input Modules for Bangla
Sayamindu Dasgupta <sayamindu randomink org> has announced ImBeng
Reloaded - a set of two new GTK input modules for Bangla. One of them
follows the Inscript layout, while the other follows the Probhat semi
phonetic layout. Details at
http://sayamindu.randomink.org/ramblings/index.php?p=68 .

!Volunteers/Beta Testers requested for Product Feedback
NeoLinux Solutions http://neolinuxsolutions.com is looking for
Volunteers/Beta Testers who are willing to try out the Indic Components
released by the Company. Contact Animesh <animesh at neolinuxsolutions.com>

!Ravikant announces the availability of [Bolnagri] Phonetic layout
The last newsletter announced a phonetic keyboard. The fact is that the
keyboard is now ready for use, improvement and further suggestions.
Download it from : http://indlinux.org/downloads/files/bolnagri.tar.gz
----
!Team Watch

The present Kannada team:

# Let's begin with the URL of the project and Screenshots.
   *URLs
     * http://kannada.sourceforge.net/ - Project Home page
     * http://sourceforge.net/projects/kannada  - Sourceforge Project page

   *Screen shots
     * http://kannada.sourceforge.net/openoffice.org/screenshots -
OpenOffice.org Screenshots
     * http://kannada.sourceforge.net/gnome-screens/screenshots.html -
Gnome Screenshots
     * http://kannada.sourceforge.net/mozilla-with-pango.png - Mozilla
rendering Kannada
     * http://kannada.sourceforge.net/xfce-panel-kannada.png - XFCE in
Kannada
     * http://kannada.sourceforge.net/kde-preview - KDE with QT 3.2.0
screenshots

# Why did this L10n start? What was the motive behind this?

  hpnadig: The project started with an aim to help localize free
software in Kannada, initially targetting, but not limited to kde and gnome.

# What are the visions & objectives of the project?

  pramod: Besides the initial aim of translating Gnome, KDE, XFCE,
OpenOffice.org, Mozilla & other FLOSS applications,     our objective
includes making sure the rendering, input, sorting, etc., works to
user's expectations. Long term vision includes more people use and
deploy the work, more applications gets translated and localized.
Another long-term objective is to work towards a greater presence of
Kannada in the public domain, say having the Kannada equivalents of
wikipedia/Gutenberg.

# What is the current status of the Project?

  pramod: We have completed nearly 5% of Gnome 2.8,  60-70% of
OpenOffice.org 1.1.2, which except for the OpenOffice bit looks quite
bare. But speaking of current status of Kannada on Linux, we do have one
font under GPL, two keyboard layouts - one inscript & one semi-phonetic
(nudi).(The latter needs IIIMF).

# Who would volunteer for the project? What is the desired profile? Does
the project need more volunteers?

  pramod: Anyone who is interested in contributing his bit to Kannada,
be it translating the software, documentation or any content or hacking
on Kannada related stuff is welcome. The project definitely needs
volunteers who are committed and are in for the long run.

# What are the plans in future with this L10n?

  hpnadig: The future plans include completion of localization for
gnome2.6, evolution, KDE 3.2 and many other free software that are on
the community work desk.

  pramod: More translations, fixing basic issues with rendering, getting
more OpenType fonts, getting a decent phonetic keyboard and hope to see
the project stabilize instead of the high & low peak of activities we
are seeing now.

# How is the funding being managed?

  pramod: Except for the work on OpenOffice.org, rest of the work did
not receive any funding. My personal opinion is funding is needed more
for translators rather than developers, since the former are rare and
translation is quite a thankless job.

# What are the problems faced by the L10n project(Both technical and
otherwise eg. Pango, OOo etc)?

  pramod: There still is plenty of work to be done both in translations
and we barely would have progressed much if not for the ~OpenOffice.org
translations which were done by Kannada Ganaka Parishath. We hope to use
OO.o's translations for Gnome, KDE & Mozilla.  Rendering has improved in
both GTK & QT, except for some minor quirks with  GTK's deletion
handling & some minor font issues.

# Indic L10n suffer from common technical problems - are you in touch
with other groups that are doing L10n?

  pramod: Yes, We do follow the progress of other language teams and
observe their processes.

----
!Help ..F1

!Debian installer to support bi-directional scripts
It has been announced in Debian  i18n list that the current version of
the  Debian  installer  supports  bi-directional scripts  like  Farsi,
Hebrew, and Arabic using libfribidi. This  means  that the  support  for
  Indic  scripts is  possible and somebody has to do the footwork.

----

Hi all,
On behalf of the Localization community in India we are happy to bring
out the first issue of the Localization Newsletter. Aim of this
newsletter is to highlight localization activities based on  Free/Open
Source Software, present a complete picture, and to serve as a
mouthpiece for all localization teams & their volunteers.

Highlights of this issue
* Headlines : Bengali, Punjabi supported languages in Gnome 2.6, Hindi
and Tamil supported in KDE 3.2
* In News Bits : PCQLinux2004 with Indic support, Devanagari & Gujarati
Opentype fonts, Mozilla build with Indic support.
* In Team watch : Sayamindu Dasgupta speaking on Ankur Bangla project.

Read complete issue at http://www.indlinux.org/nl/nl150404.html
A pdf of it is available at http://www.indlinux.org/nl/nlvol1.pdf (238KB)

Comments are welcome, and can be mailed to the editorial team or posted
on http://www.indlinux.org/wiki/index.php/NewsletterFeedback

If you would like to recieve copy of newsletter regularly you can
subscribe to the mailing list
http://lists.sourceforge.net/lists/listinfo/indlinux-news

With best wishes,
Karunakar
Coordinator, IndLinux.org

<?xml  version="1.0" ?><html>
<head>
<title></title>
</head>
<body>
<div align="left"><font face="Arial"><span style="font-size:10pt">Workshops on Indian language software development will be conducted at Bangalore, 
Mumbai, Hyderabada, Chennai and Delhi during March and April. For more details and 
registration, please visit http://www.bhashaindia.com/events/rlsd/index.aspx</span></font></div>
<div align="left"><br/>
</div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Regards,</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Pavanaja</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">---------------------------------------------------------------------------------------------</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">Dr. U.B. Pavanaja</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt">CEO, Vishva Kannada Softech</span></font></div>
<div align="left"><font face="Arial"><span style="font-size:10pt"><i>Think Globally, Act locally</i></span></font></div>
</body>
</html>

Hello Everyone,

Accessing Indian language applications over the internet is
hampered by the fact that Unicode support is not available
on Windows 95 and 98. IBM alphaWorks contains an IME
(Input Method Editor) for Indic languages that does the
following:
1. Facilitates input of Unicode text for Indic languages on
    older Windows machines.
2. Uses Open Type Fonts to display the characters being
    entered into the text area.
3. Uses INSCRIPT layouts for different Indian languages.
4. Displays an on-screen layout for ease-of-use.
5. Applies to the following Indian languages:
    Hindi/Marathi/Konkani/Sanskrit, Gujarati, Tamil, Telugu,
    Bengali/Assamese/Manipuri, Punjabi, Kannada,
    Malayalam and Oriya.

You will need an open type font for the script that you
want to type in.

Download it from:
http://www.alphaworks.ibm.com/tech/indicime

Evaluate it at :
https://secure.alphaworks.ibm.com/eval/indicime

If you think these kinds of technologies are important
for Indian language computing over the internet, tell us
more at:
http://www.alphaworks.ibm.com/forum/indicime.nsf

Visit http://www.ibm.com/software/globalization for extensive
information and advice on building solutions in the languages of
your users, partners and customers.

Regards,
Abhijit
____________________________

On Tue, 27 Jan 2004, Guntupalli Karunakar wrote:
> On Tue, 27 Jan 2004 13:37:16 +0900 (KST)
> Jungshik Shin <js...@ma...> wrote:

> > This is to announce that I put up a Mozilla binary with Pango for
> > complex script rendering at ftp.mozilla.org. It's available at
> >
> > ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i386-pc-linux-gnu-gtk2-pango.tar.gz
> >
>  seems a small typo, no i386 file but found a i686 one
> ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i686-pc-linux-gnu-gtk2-pango.tar.gz
>

Thank you for catchging the typo. BTW, there's also a typo in the link
to README file. It is

 ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/README-pango  (instead of READEM-pango)

  Jungshik

On Tue, 27 Jan 2004 13:37:16 +0900 (KST)
Jungshik Shin <js...@ma...> wrote:

> 
> Hi,
> 
> This is to announce that I put up a Mozilla binary with Pango for
> complex script rendering at ftp.mozilla.org. It's available at
> 
> ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i386-pc-linux-gnu-gtk2-pango.tar.gz
> 
 seems a small typo, no i386 file but found a i686 one
ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i686-pc-linux-gnu-gtk2-pango.tar.gz

-- 
Dream, Dream, Dream
Dreams transform into thoughts
And thoughts result in action.   -- Kalam

---------------------------
* Indian Linux project    *
* http://www.indlinux.org *
---------------------------

Hi,

This is to announce that I put up a Mozilla binary with Pango for
complex script rendering at ftp.mozilla.org. It's available at

ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/mozilla-i386-pc-linux-gnu-gtk2-pango.tar.gz

It's compiled with gtk2, xft and my patch for mozilla bug
215219 (http://bugzilla.mozilla.org/show_bug.cgi?id=215219).

Please, spread the words so that as many people as possible can benefit
from the build. If you use a type 1 postscript font for Western langgroup,
you may have a trouble with Latin letters. There are two ways to solve
the problem. One is NOT to use type 1 postscript fonts and the other is
to upgrade Xft, fontconfig and Pango the latest.  Please, refer to the
following README file for more details.

ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/contrib/READEM-pango

Jungshik

From Indic Unicode mailing list. Pl note the Indic sorting paper by Cathy 
(http://www.unicode.org/notes/tn1/). Post your opinion if there is any dicrepancy.

I will be meeting her personally in Feb. (between 18 -20). If any of you have any issues in 
Indic sorting, please send me a detailed write-up. I will take it up with her. I am very happy to 
say that the Kannada sorting is now perfect in Unicode and Windows because of my efforts.

Rgds,
Pavanaja

------- Forwarded message follows -------
To:             	un...@un...
Subject:        	[indic] Three new Technical Notes posted
Date sent:      	Fri, 23 Jan 2004 14:46:15 -0800
From:           	Rick McGowan <ri...@un...>

Three new Unicode Technical Notes are now available on the Unicode website.

The main Tech Notes page is here:
	http://www.unicode.org/notes/

The new notes are:

  #11 Representing Myanmar in Unicode: Details and Examples
	by Martin Hosken & Maung Tuntunlwin

  #12 UTF-16 for Processing
	by Markus Scherer

  #13 GDP by Language
	by Mark Davis

The notes are all accessible through the left-side "navigation bar" on the  
main Tech Notes page.

Regards,
	Rick

------- End of forwarded message -------
---------------------------------------------------------------------------------------------
Dr. U.B. Pavanaja
CEO, Vishva Kannada Softech
Think Globally, Act locally

Regards,
Abhijit
----- Message from Tex Texin <te...@i1...> on Thu, 08 Jan 2004 01:25:24
                                                                -0500 -----
Subject:25th Unicode Conference - March 31-April 2, 2004 - Washington,
D.C., USA
                                   Unicode in Government:
                             Building a Multilingual Infrastructure
                                http://www.unicode.org/iuc/iuc25
                                      Washington D.C., USA
                                    March 31 - April 2, 2004

**************************************************************************
Register now and save with Conference + Hotel Early-bird Discounted Rates!
**************************************************************************

Program Overview
================
The 25th Internationalization and Unicode Conference will focus on
solutions
that address the language and multilingual requirements of governments and
industries around the world.

Technologies built on the Unicode Character Standard make it feasible today
to build a multilingual infrastructure that satisfies these requirements.
This conference will examine the requirements and explore recent advances
in the state of the art, as well as traditional best-practices.

The Washington DC venue was specifically chosen to allow discussion and
peer networking around the needs of government including topics such as
U.S. Homeland Security, and the European Union's challenges supporting all
its official languages.

The Internationalization & Unicode Conference is the premier technical
conference worldwide for both software and Web internationalization.

This program features:

* Enhanced Unicode tutorial (incorporating Unicode 4.0)

* Sessions and panels on working with languages within government

* Updates to the popular tutorials on: Web Internationalization,
  Writing Systems,  Distributed Systems, and Authentic Arabic

* Several completely new tutorials such as: Internationalization Project
  Planning, Internationalized Software Testing

* Track on Localization organized and sponsored by The Institute of
  Localisation Professionals (TILP)

* Sessions on internationalization, including topics such as:
  Scripts, platforms, locales, legacy data, transliteration,
  Web internationalization, rendering, and conversion

* Sessions on programming: Java, .NET, IBM ICU, Oracle, and Testing

* Numerous case studies

CONFERENCE HIGHLIGHTS

Diverse Topics and Formats
---------------------------
The conference features tutorials, lectures, and panel discussions that
provide coverage of standards, best practices, and recent advances in the
globalization of software and the Internet.

Emphasis on Current Government Needs
------------------------------------
Language and multilingual requirements of governments and industries around
the world will be addressed in several sessions as well as in the
Government Track devoted to standards and resources for government workers.

Everette Jordan, Director of the United States Government National Virtual
Translation Center (NVTC), will be a keynote speaker, kicking off the
conference.

Exhibitor's Showcase and Panel Sessions
---------------------------------------
A forum that highlights the latest advances in language services, tools
and technologies.

Unicode 4.0
---------------
The Unicode tutorial and many other tutorials and breakout sessions are
updated to cover the most recent release of the Unicode Standard. This
conference is your best opportunity to learn about Unicode and
internationalization directly from the experts.

WHO SHOULD ATTEND?

If you have a limited training budget, this is the one Internationalization
conference you need.  Send staff that are involved in either
Unicode-enabling software, or internationalization of software and the
Internet, including: managers, software engineers, systems analysts, font
designers, graphic designers, content developers, Web designers, Web
administrators, system administrators, technical writers, and product
marketing personnel.

CONFERENCE WEB SITE, PROGRAM and REGISTRATION

The Conference Program and Registration form are available at the
Conference Web site:

      http://www.unicode.org/iuc/iuc25

CONFERENCE SPONSORS

Agfa Monotype Corporation
Basis Technology Corporation
World Wide Web Consortium (W3C)
XenCraft

GLOBAL COMPUTING SHOWCASE

Visit the Showcase to find out more about products supporting the
Unicode Standard, and products and services that can help you
globalize/localize your software, documentation and Internet content.

Sign up for the Exhibitors' track as part of the Conference.
For more information, please see:
             http://www.unicode.org/iuc/iuc25/showcase.html

CONFERENCE VENUE

The Conference will take place at the:

             Hilton Alexandria Mark Center
             5000 Seminary Road
             Alexandria, VA 22311
             Tel: (703) 845-1010
             Fax: (703) 845-7662

CONFERENCE MANAGEMENT

             Global Meeting Services Inc.
             8949 Lombard Place, #416
             San Diego, CA 92122, USA

             Tel: +1 858 638 0206 (voice)
             +1 858 638 0504 (fax)

             Email: in...@gl...
             or: con...@un...

THE UNICODE CONSORTIUM

The Unicode Consortium was founded as a non-profit organization in 1991.
It is dedicated to the development, maintenance and promotion of The
Unicode Standard, a worldwide character encoding. The Unicode Standard
encodes the characters of the world's principal scripts and languages,
and is code-for-code identical to the international standard ISO/IEC
10646. In addition to cooperating with ISO on the future development of
ISO/IEC 10646, the Consortium is responsible for providing character
properties and algorithms for use in implementations. Today the
membership base of the Unicode Consortium includes major computer
corporations, software producers, database vendors, research
institutions, international agencies and various user groups.

For further information on the Unicode Standard, visit the Unicode Web
site at http://www.unicode.org

                           *  *  *  *  *

Unicode(r) and the Unicode logo are registered trademarks of Unicode,
Inc. Used with permission.

>>>>> "alok" == alok kumar <alo...@so...> writes:

    alok> What I gather is that all we need is a different set of
    alok> makefiles for the different installations. The dependencies
    alok> - ie sources, documents (*.sgml) need not be duplicated.
    alok> So, the Makefile would contain stuff like if(debian) then
    alok> make -f debianmakefile else ...  etc and everything else
    alok> stays the same. Thus, the specific makefiles are
    alok> different. At the same time the dependencies are stored only
    alok> in one location. A change to a particular makefile should
    alok> set the "dirty bit" on for the others - to see if there is
    alok> an impact on the others. Is that what is implied?  

Yes, IIUC, the sources. What the makefiles currently do is to set up
environment variables, pathnames to tool binaries, tool command line
parameters etc..... Then the tools are invoked in the correct
sequence. Since all these depend on the OS specific file system
layout, versions of tools ( for example the jade command line problems
you had earlier ), etc, I feel its best to have separate branches of
the Makefiles. In fact, we could even have the Makefiles re-written in
GNU make on GNU/Linux systems, to bring down package dependencies....

-- 
ch...@sd...
SDF Public Access UNIX System - http://sdf.lonestar.org

Cherry George Mathew writes: 

> 
> Since we're using CVS, we could merge the HEAD branch periodically,
> with the port branch, and work out issues as and when they come. But
> AFAICS, there really is not too much work to be done on the
> doc/share/mk tree. We should get it up and running, and focus

What I gather is that all we need is a different set of makefiles for the 
different installations. The dependencies - ie sources, documents (*.sgml) 
need not be duplicated.
So, the Makefile would contain stuff like
if(debian) then make -f debianmakefile
else ...
etc
and everything else stays the same. 

Thus, the specific makefiles are different. At the same time the 
dependencies are stored only in one location. A change to a particular 
makefile should set the "dirty bit" on for the others - to see if there is 
an impact on the others. 

Is that what is implied?
Alok
-- 
                       alok_kumar à¤à¤ softhome à¤¡à¥à¤ net
                     http://devanaagarii.net/hi/alok/blog
                   Can't see Hindi? http://devanaagarii.net
             http://groups.yahoo.com/group/linux-bangalore-hindi/
      Discuss devanagari at http://groups.yahoo.com/group/devanaagarii/ 

 >>>>> "alok" == alok kumar <alo...@so...>
writes:

alok> Hi Cherry, This is interesting, particularly
since I haven't

[...]

alok> Would this indic-doc-toolchain.deb file be such
that deb2rpm
alok> works on it?

Hmm.... I'm really not sure. I'm made the debian
packages by following
instructions from the debian.org site. I guess there
is no particular
reason why they shouldn't work with deb2rpm, if
deb2rpm works with
other debian package. Perhaps you could try it and
send a report ?

>> II) _______The_src_makefiles_______ The Makefiles
within
>> doc/share/mk assume a FreeBSD directory layout.
This is quite

[...]

>> trying to make it portable would bloat the Makefile
code a lot
>> (writing wrapper variables, #ifdefs etc. )

alok> What is the cost of having a huge makefile? Does
it o
alok> increase build time?

That one is for Koshy. I'm a newbie with BSD make.

alok> o reduce readability ?

IMHO, yes. We don't want debian developers groking
through BSD
"clutter" and vice versa. Not looking for a flame war
here, of
course.

>> On the other hand, if we have a maintainer <->
upstream

[...]

>> be tweaked and debugged to its best.

alok> The way this currently happens is - Koshy makes
the changes,
alok> as and when required, for everything to work on
FreeBSD. And

[...]

alok> automate them? Actually, yes, by the cvs commit
logs one can
alok> make out what changes would be relevant for the
other
alok> branches. So this could be workable. The
questions that
alok> arise are, o how many branches do we keep? One
for debian,
alok> another for RH, one more for mandrake, not to
forget
alok> win*/cygwin o how do the changes in one
branch(not
alok> necessarily the bsd one) get merged to the
others?

Yes, why not ? Look at the successfull Open Source
distributions out
there: NetBSD, FreeBSD, Debian...... Each of them has
a
Maintainer <-> Upstream working model. Each of them
has a bug
tracking system with which specific bugs are allocated
to specific
maintainers. The whole issue here is how to delegate
responsibility. If people volunteer to offer working
packages, update
them continually, document them, and contribute their
additions back
to the upstream authors, the quality of the whole
package improves. If
OTOH volunteers offer features, the responsibility of
code management
is divolved among many people, and as the saying goes,
"everybodys'
job, is nobody's job". Take a look at the number of
individual
maintainers of the linux kernel, each person
struggling with enormous
code bases, and being less able to give effective
attention to quality
( remember the Dec 24th attack on Debian servers ? )
to get a feel for
what I'm saying.

Since we're using CVS, we could merge the HEAD branch
periodically,
with the port branch, and work out issues as and when
they come. But
AFAICS, there really is not too much work to be done
on the
doc/share/mk tree. We should get it up and running,
and focus
attention on other crucial areas like OS Image
development etc.

Best,

Cherry.
-- 
ch...@sd...
SDF Public Access UNIX System -
http://sdf.lonestar.org

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Hi Cherry, 

This is interesting, particularly since I haven't been able to do the 
handbook build successfully on RH8 since the past month. 

> My suggestion is that we should move this virtual
> package ( indic-doc-toolchain.deb ) to the debian

Would this indic-doc-toolchain.deb file be such that deb2rpm works on it? 

> 
> II) _______The_src_makefiles_______ 
> 
> The Makefiles within doc/share/mk assume a FreeBSD
> directory layout. This is quite different from the
> debian Filesystem Heirarchy Standard [2] 
> 
> There are two solutions: 
> 
> 1) Provide an alternate cvs branch forked off the
> current main branch, and periodically merge from the
> main branch.
> 2) Provide OS specific hooks within the current branch
> and make the current build system portable. 
> 

> trying to make it portable would bloat the Makefile
> code a lot (writing wrapper variables, #ifdefs etc. ) 
> 

What is the cost of having a huge makefile? Does it
o increase build time?
o reduce readability ? 

> On the other hand, if we have a maintainer <->
> upstream relationship with the indic-port, where the
> FreeBSD branch, being the branch where all the action
> happens is treated as the upstream code, and the
> individual OS port is treated as maintainer ports,
> each OS port will have responsible owners and be
> tweaked and debugged to its best. 
> 

The way this currently happens is - Koshy makes the changes, as and when 
required, for everything to work on FreeBSD. And the rest(if any) follow, 
making the corresponding changes for their installations. I'm sure(or at 
least hoping) that wouldn't be the case in the long run. People working on 
various installations would be making changes to various parts.
Now, imagine a situation where developers are working on various sections of 
the handbook, on different installations. They may make some changes to the 
makefiles. Under the current system, other users would then be *forced* to 
make appropriate changes to make it work on their installations the next 
time they do a build. 

If we have separate makefiles for different installations, the changes would 
have to be done manually. Is there a way to automate them? Actually, yes, by 
the cvs commit logs one can make out what changes would be relevant for the 
other branches. So this could be workable. The questions that arise are, 

o how many branches do we keep? One for debian, another for RH, one more for 
mandrake, not to forget win*/cygwin
o how do the changes in one branch(not necessarily the bsd one) get merged 
to the others? 

I'm new to cvs so many questions may have obvious answers. 

Alok
-- 
                       alok_kumar à¤à¤ softhome à¤¡à¥à¤ net
                     http://devanaagarii.net/hi/alok/blog
                   Can't see Hindi? http://devanaagarii.net
             http://groups.yahoo.com/group/linux-bangalore-hindi/
      Discuss devanagari at http://groups.yahoo.com/group/devanaagarii/ 

Hello List,

I have a couple of questions about 

I) _____The debian toolchain port______

This is how I've currently done it:

1) Create a .deb file with all the requisite
dependencies.

2) Provide a Debian apt-get compatible directory
layout a.k.a a "Debian Archive".[1]

3) Provide further .debs (like for the peps package )
within this directory.

4) Point apt-get to the directory layout

5) Provide instructions to the user on how to
configure the apt-get tree.

Debian is a heavily centralized packageing system, and
depends on preset configurations, like for example the
preformatted directory layout. 

While Koshy suggested that I provide a make file build
tree to build .deb files themselves, I feel that
debian package management is a chore to be undertaken
by a package maintainer. Opening this to the user is
redundant and error prone ( because the dpkg debian
package management system is a formidable system to
master - and it requires a set of packages for package
maintainance. ).

My suggestion is that we should move this virtual
package ( indic-doc-toolchain.deb ) to the debian
repository at debian.org, along with the additional
package ( peps.deb ), so that the average user just
needs to do:

apt-get install indic-doc-toolchain

to get the toolchain dependencies installed.

II) _______The_src_makefiles_______

The Makefiles within doc/share/mk assume a FreeBSD
directory layout. This is quite different from the
debian Filesystem Heirarchy Standard [2]

There are two solutions:

1) Provide an alternate cvs branch forked off the
current main branch, and periodically merge from the
main branch.
2) Provide OS specific hooks within the current branch
and make the current build system portable.

I personally prefer 1), because the FreeBSD project
and the Debian project are two entirely different
projects with their own goals, and since the build
system is based on the FreeBSD doc-toolchain, and
since it assumes things about the filesystem layout,
trying to make it portable would bloat the Makefile
code a lot (writing wrapper variables, #ifdefs etc. )

On the other hand, if we have a maintainer <->
upstream relationship with the indic-port, where the
FreeBSD branch, being the branch where all the action
happens is treated as the upstream code, and the
individual OS port is treated as maintainer ports,
each OS port will have responsible owners and be
tweaked and debugged to its best.

Please comment.

Best,

Cherry.

PostScript: I won't be doing indic-related work until
the beginning of next month. It would be nice if we
could reach a consensus by then.

[1] 
http://www.debian.org/doc/debian-policy/ch-archive.html

[2]
http://www.debian.org/doc/packaging-manuals/fhs/

__________________________________
Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus

Jungshik Shin writes: 

>   I already got and agreed to your point. Otherwise, I wouldn't have 
> written the following: 
> 
> JS>  this is not to say that we don't need a good FAQ-like document. 
> 
>    and 
> 
>  JS> Alok, why don't you  update update your page as I wrote you a week 
> ago?
>  JS> Then, I'll refer to it in the international release notes..   
> 

Sure, thanks for the suggestion. I'll do that.
Until that happens, this discussion is archived at
<http://sourceforge.net/mailarchive/forum.php?thread_id=3687919&forum_id=296 
7>
http://sourceforge.net/mailarchive/forum.php?thread_id=3687919&forum_id=2967 

As an aside, would you guys like to subscribe to 
ind...@li...? This is not the end of the 
story, I'm sure, and subscription would save us the time spent in moderating 
valuable posts from you in the future. 

Alok 

-- 
                       alok_kumar à¤à¤ softhome à¤¡à¥à¤ net
                     http://devanaagarii.net/hi/alok/blog
                   Can't see Hindi? http://devanaagarii.net
             http://groups.yahoo.com/group/linux-bangalore-hindi/
      Discuss devanagari at http://groups.yahoo.com/group/devanaagarii/ 

Sumedh Thakar wrote:

>>that way more people will get onboard.
>>    
>>
A lot better would be to just make a binary distribution with gtk2 + xft 
+ my patch for bug 215219 and put it up at ftp.mozilla.org as a 
contributed binary. Then, people wouldn't have to compile at all. Not 
all people can compile from the source. I'm gonna do that once 1.6 is 
released.  And, I'll try to  land my patch for bug 215219 in 1.7 
development cycle.

>>Hope you get my point .. thanx!
>>    
>>
   I already got and agreed to your point. Otherwise, I wouldn't have 
written the following:

 JS>  this is not to say that we don't need a good FAQ-like document.

    and

  JS> Alok, why don't you  update update your page as I wrote you a week 
ago?
  JS> Then, I'll refer to it in the international release notes..  

  Jungshik

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (14)
2002	Jan (25)	Feb (90)	Mar (41)	Apr (16)	May (8)	Jun	Jul (37)	Aug (35)	Sep (62)	Oct (37)	Nov (22)	Dec (7)
2003	Jan (16)	Feb (19)	Mar (10)	Apr (5)	May (26)	Jun (11)	Jul (35)	Aug (4)	Sep (14)	Oct (5)	Nov (5)	Dec (10)
2004	Jan (25)	Feb (2)	Mar	Apr (1)	May	Jun	Jul (10)	Aug (2)	Sep (2)	Oct (1)	Nov (9)	Dec
2005	Jan	Feb	Mar	Apr	May	Jun	Jul (2)	Aug	Sep	Oct (1)	Nov (1)	Dec (1)
2006	Jan	Feb	Mar (1)	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (1)	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov (4)	Dec

indic-computing-devel Mailing List for The Indic-Computing Project (Page 2)

indic-computing-devel — Discussing the development of tools for Indian language information processing