Re: [Gnome-print] First draft of new encoding routines

[Lauris Kaplinski <lauris ximian com>]

Hello!

On 19 Jun 2001 05:03:48 -0400, Scott Gifford wrote:
> Originally it was licensed under the standard GPL, though, so
> certainly you had permission to distribute it...

Ah, yes, of course ;-) But it would effectively turn the license
of full gnome-print to GPL (instead of LGPL), what is not what gnome 
project has planned ;)

>     LK> I will place your code into separate subdirectory filter under
>     LK> libgnomeprint at first, so we create temporary .la library
>     LK> during compilation. I you plan (we/somebody plans) to
>     LK> distribute these in separate library, we can easily switch
>     LK> over using it.
>     LK> 
> 
> I haven't quite decided what to do about this.  It looks like maybe
> Mozilla could use this filter code, too, which would mean I would need
> to dual-license it under the LGPL and Mozilla's MPL.  For it to become
> a part of gnome-print, I would probably have to assign copyright to
> the FSF, which would make it impossible for me to do this
> dual-licensing.  If somebody has a solution for this, I could just
> make everything gnome-print-filter*, make the official home of this
> work gnome-print, and just use the relevant parts for other projects
> as needed.  Otherwise, I will probably need to maintain it as a
> seperate library to maintain copyright.  Of course, it's LGPL, so it
> isn't really a big problem either way, but it would be more convenient
> for everybody if we could just make all of this a part of gnome-print.

At moment you do not have to assign copyright to anybody for it
distributed as part of gnome-print.

>     CC> - Use a better Prefix. "Filter" and "filter_.." is too
>     CC> vauge. Since this symbols will end up in gnome-print, an app
>     CC> that uses gnome-print might have a symbol crash, think about
>     CC> filter_free for example.
> 
>     LK> As of namespace, well, little google search would do good. I
>     LK> checked 'filter_init' and it gave me quite a long list of
>     LK> matches (although I had no time to check, whether any of these
>     LK> could cause real problems).  I would suggest prefixing
>     LK> everything with something like sff_ (Scott Free Filter). There
>     LK> were some matches to sff too, but these seemed to come from
>     LK> some higher-level language.  The real problem is, that most
>     LK> 2-letter namespaces are already occupied, as are big number of
>     LK> 3-letter ones. And you cannot actually use too long prefix, as
>     LK> AFAIK there are some silly limits of distinguishable name
>     LK> length on some systems. Plus long prefixes are extremely
>     LK> difficult to read/type/distinguish.
> 
> If the library becomes part of gnome_print, I'll probably use
> gnome_print_filter; do you think that's too long?  I'm not really
> familiar with the variety of compilers out there.

Think this out. At moment I'll include it privately - i.e. no public
.h file installed. If you have decided either to move it permanently
into gnome-print, or keep as separate library, we'll resolve it easily.
gnome_print_ prefix is OK.

>     CC> - You don't seem to want to use glib functions.  assert,
>     CC> strdup, malloc, realloc can be replaced with g_assert,
>     CC> g_strdup, g_malloc, g_realloc.  Maybe you don't want this code
>     CC> to depend on glibc. Is this your intention ?
> 
> I wrote the code in the manner I'm most familiar with, and that
> involves using the standard C functions.  I tried to do all of the
> error checking that the glib versions provide, so there shouldn't
> really be any disadvantage to this.
> 
> I've been looking around to see some of the places this code could be
> useful, and have found a few (particularly Mozilla) that compile on
> platforms where glib is not easily available, so I'd like to continue
> using the standard C functions.
> 
> Let me know if you can think of any problems this causes (apart from
> my own inconvenience).

Well, I cannot tell much about possible problems. Usually these are
dug out by people compiling gnome code on sparc and ppc machines - but
if you have multi-platform in mind anyways, you are prepared to target
these anyways.

>     filter_hexenc.c:83:  const char tohex[16] = "0123456789abcdef";
> 
> #defining a constant for this didn't seem to help in any way for that
> code.

;-)

> I also #defined the line-length constant and some other constants that
> I should have #defined from the beginning.
> 
> There may be a few other places constants make sense; when there are
> no architectural issues, I'll go over the code with a fine-tooth come
> looking for things like this.
> 
>     CC> [The rest of the comments fall on the personal coding style,
>     CC> inside gnome-print we have several coding sytles mixed. This
>     CC> is not what we want and should standarize, I just don't want
>     CC> to make this even worse if possible. Hoever, this is a
>     CC> separate library so if you have strong preferences you can
>     CC> leave it like that]
> 
>     LK> I do not care about coding style, as long as code is clearly
>     LK> separate unit (as your filter code will be), and does not need
>     LK> extensive maintenance/bugfixing on my side. But if I have to
>     LK> do that, I tend to convert everything to my personal style ;-)
>     LK> That is quite logical too, as every programmers eye is trained
>     LK> with certain visual patterns in code, so finding bugs from
>     LK> differently formatted code is much bigger pain.
> 
> At least while I'm doing most of the work on this library, I'd prefer
> to keep it in my own style.  As Lauris mentions, I am accustomed to
> this style, and can both code and debug much more quickly using it.
> If we decide to standardize on a style throughout gnome-print, I would
> be willing to conform to it, though.
> 
> Sorry, old habits die hard.  :)

There is nothing to be sorry about. It is your code, and we very much
hope we do not have to do extensive debugging of it ;)

> Yes, there is a test suite included in the "t" subdirectory of the
> tarball.  Run the program "test" in there for a 15-minute, quite
> thorough test of your build of the filter stuff.  "testwith" is a
> script that makes it easier to test individual cases, and is also
> included.  They do the encoding with "filtertest", included in
> filter.tar, decode the results with GhostScript, and make sure it's
> identical to the original file.  These tests proved incredibly useful;
> they helped me track down at least a dozen bugs.
> 
> Is there any infrastructure for including these tests in gnome-print?
> If the filters get completely folded into gnome-print, I'd hate to
> lose them.

There is bunch of tests in 'tests' subdirectory. We can either keep test
together with code (in which case it can .o files directly), move it
to tests or libgnomeprint directory. in which case it can just link with
freshly built library.
I think that at moment it may reside together with code, but eventually
tests is right place.

Best wishes,
Lauris Kaplinski