Re: [tlug] Printers for linux, was: refurbished Thinkpad X60 with Coreboot & Linux

["Stephen J. Turnbull" <stephen@example.com>]

Benjamin Tayehanpour writes:

 > > Except that all the distros seem to have decided that
 > > CUPS is the way to go.
 > 
 > Hopefully this increased amount of attention will lead to more
 > documentation being written.

Maybe, but my experience with that has been rather disappointing.
Projects where documentation is neglected typically do not change
their practices simply based on public pressure.  I think there's also
a pretty strong pressure on copycat projects to get their user
documentation up to snuff, so the documentation they produce ends up
like commercial product documentation with video tutorials and screen
shots of menus and dialogs with the relevant entry fields circled in
red, you know the drill.

Even with CUPS, I have to admit that their "documentation for the rest
of us" is pretty good.  But from my point of view, CUPS does have a
lot of accessible and repairable moving parts under the cover, and
documentation on how to work with that is woefully sparse.  And I
don't think that's going to change.

 > > public and freely licensed.  And it's not very useful when you report
 > > a bug (the code's the doc, so whatever it does is correct ...!)
 > 
 > Well, not really. That's like saying a typo in the doc would change
 > reality to fit the mistake. Nothing written by man can be infallible;
 > people believing in such nonsense usually end up killing each other
 > over it.

Not at all.  If there was only doc, that makes a certain kind of
sense.  But where there is doc and code, there are several possible
outcomes -- I didn't say the doc was always right, only that the doc
makes it possible to be *sure* there's a bug when doc and code differ.

Broadly, they are make the doc fit the code, make the code fit the
doc, and make both doc and code fit the specification that was
intended.  (And of course there's the X.org approach, which is to
shove your head in the sand and claim that "nonblocking" doesn't mean
"in the face of error system states" if that would require another
branch in your event loop.  Although actually they eventually put my
patch in function, since experience showed it really sped up the
function in practice (ie, compared to the infloop).)

 > > lose or duplicate Japanese text in many cells for .xlsx files).
 > 
 > Well, that's what you get for working in a non-native file format.

No, that's what you get for collaborating with people who work in
native file formats for *their* system.  I really can't force my
colleagues or my kids' teachers to use OOo or lo.

Eg, did you know that top computer science departments have settled on
Word files as their preferred format for admissions-related documents
(student application essays, recommendations)?

 > > Back at school, I'd love to be able to force the students to use less
 > > featureful presentation software.  It's always a struggle to get them
 > > to spend as much time on the words as on the fonts and special
 > > effects....
 > 
 > My word. You've tried forcing Xemacs on them, haven't you? :-P

No, I haven't.  XEmacs *used* to have a rather flexible and
user-friendly graphical menu for setting default fonts, and excellent
convenience APIs for creating faces.  Had that still been true, yes, I
would have tried.

But then two things happened: GNU Emacs got serious about GUI[1], and
antialiased fonts.  The former turned what used to be an elegant API
implementation into a mess, as GNU uses an ever-changing structure
built of lists of alists of lists of plists (ad nauseum) to represent
various GUI properties of interest in calculating faces, and we had to
patch our implementation to match.  (And they declared this structure
to be "internal", so backward compatibility didn't apply....)

The latter was simply so attractive that even without menus, after
about two years of vetoing inclusion of various Xft patches because
they didn't include documentation or updates to the face configuration
API, I was forced to swallow a patch that didn't include those
features, on the grounds that the "many eyes would fix such shallow
bugs quickly."  7 years later, although I ended up doing a lot of
documentation, the UIs for dealing with fonts are still basically
non-existent.  At least we've fixed the problem that prevented
specifying Xft/fontconfig fonts from Lisp (actually only a small patch
as it turned out, but the menus and customize are much harder).  When
we first distributed betas with the patch included, the only way to
set Xft fonts was through X resources!


Footnotes: 
[1]  RMS just started a thread about providing a mode for WYSIWYG word
processing.  If they seriously try that, XEmacs will have an excellent
chance to catch up and pass them in actually desirable features by 2020!