[Pkg-ime-devel] RFS: scim-waitzar, libwaitzar (re-submission) Attn: Paul Wise

[S'orlok Reaves]

Ah, now we enter into the joyous legal details. I'll do my best to 
be as helpful as possible in this regard; please let me know if you need
any clarifications. I only had to re-build one package this time:

http://mentors.debian.net/debian/pool/main/s/scim-waitzar/


> Which fonts are these? I'm wary of adding fonts to source packages;
> usually either the font is a copyright violation or should
> be packaged separately.
It was just the Myanmar 3 font, which (according to a page on fedoraproject.org)
is LGPL 2+.
I understand your concern, though, so I removed Myanmar3.ttf, changed the default
Myanmar font to Padauk.ttf, and added a dependency on ttf-sil-padauk.

The "fonts" directory now contains ONLY the font metrics (xml) files for each
of the fonts I use in the documentation. This is ok, right? There's certainly
no glyph data in the package. I can remove these xml files if they violate copyright, it's just that they're fairly difficult for docbook newbies to generate at run-time.


> Note that fop is in contrib (except in experimental), so
> you should either target experimental instead of unstable or move the
> package to contrib.
Unfortunately, that defeats the purpose of this package. Scim-waitzar is meant
for everyday use by Myanmar users of Debian, and I also hope to get it into the
"Language" defaults for Ubuntu --so I really can't target experimental or contrib. 

I came up with another solution: scim-waitzar-doc now uses only xsltproc, and outputs
an html file. The makefile contains a "pdf" target, in case a user wants to generate 
the pdf documentation. scim-waitzar ships the pre-generated pdf, so people who
want to print the user's guide get a nice shiny pdf. 

This solution leverages docbook's flexibility in generating various different formats.


> Hmm, FSVO 'source code' and 'program', this
> violates DFSG #2.

Let me see if I can clarify the role of Myanmar.model; I don't think this is a 
violation of the spirit of the DFSG. 
For anyone following this discussion, the relevant line is:
"The program must include source code, and must allow distribution in source code as 
well as compiled form."

...in particular, the first half (since libwaitzar allows re-distribution of anything
in the repository). 

Myanmar.model is simply a re-generated form of MyanmarList_v2.txt. The latter is simply 
a list of mappings:
myanmar_word = romanisation
...while the former is basically just a serialized hash table containing all these mappings.
Myanmar.model is optimized for speedy lookup and minimum size. If you simply copy the contents
of MyanmarList_v2.txt into mywords.txt, scim-waitzar will load the EXACT SAME romanisation
on startup, it'll just take a few seconds longer. 

Myanmar.model also adds trigrams, to try and help typists by guessing the current word 
from the previously typed words. The choice of trigrams is subjective, and --although I 
wrote my own code to generate them-- trigrams can be generated by any decent-quality
natural langauge processing library. (I have seen free implementations).

The entirety of the WaitZar model is open-source. 
Moreover, even the trigrams are open-source. They are described directly in
Myanmar.model, which is a text-based file, and whose format is documented in the 
library's comments for those who want to hack it.

My overall feeling about this is summed up here:
1) Generating Myanmar.model at run-time is not appropriate, and way outside the scope
of a romanisation library.
2) Myanmar.model is essentially a cached version of Myanmarlist_v2.txt, with a few additional
non-essential features, which is only slightly less readable than MyanmarList_v2.txt. They
are both "source".

Of course the mentors have the final say in this. But I truly feel that my package is 
presented in the full spirit of open-source software.


> Hmm, experimental lintian tags, didn't know about
> those. Thanks
Sure thing! 


As always, please let me know what's required and I'll do my best to work my package around it. I've invested a lot of work into this package, and I'm willing to go the extra mile to get it accepted.
-->Seth