Re: [fontforge-devel] [fontforge-users] Where is the changeWeight code?

[<ms...@an...>]

On Sat, 10 Jan 2015, Werner LEMBERG wrote:
> Well, I haven't checked it this time, but previously such error
> messages always indicated very serious issues.  Given that we are

Not my experience.  My main use of FontForge has been in a very similar
context, merging and de-overlapping fonts in the Tsukurimashou Project
under script control.  Until recently, it frequently messed up the font
data; but it has always been very chatty to stderr, producing large
numbers of meaningless-to-users messages regardless of whether the font
data was messed up or not.  These are not only messages that include the
word "error" but also many like "SplineFontPieceMeal() going unhinted..."
that do not seem to describe anything abnormal.  If I applied the standard
of no alarming or confusing messages appearing on stderr ever, then I
simply couldn't use FontForge.

I also couldn't use any GNOME or KDE software, all of which produce
massive amounts of similar nonsense to stderr and stdout during normal
operation.  For instance, here's a small part of the output when I view a
perfectly innocuous PDF file with Okular, with no perceptible incorrect
behaviour:

okular(3055)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3055)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3055)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3055)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
okular(3055) PDFGeneratorPopplerDebugFunction: [Poppler] "Error:
parseAction: Bad annotation action for URI 'NULL'"
okular(3055) PDFGeneratorPopplerDebugFunction: [Poppler] "Error:
parseAction: Bad annotation action for URI 'NULL'"
okular(3055) PDFGeneratorPopplerDebugFunction: [Poppler] "Error:
parseAction: Bad annotation action for URI 'NULL'"

I don't think "no meaningless messages to stderr/stdout" is a reasonable
standard to demand of GUI software in general - and FontForge is
at heart a GUI package, even when run with a script.  When software runs
in a GUI the user usually doesn't see stderr/stdout at all, and I think
that leads developers (who DO see that output) to not bother removing the
debugging output they may add from time to time.  This output does not
always meaningfully indicate to ordinary users whether the software is
functioning normally.  Not even when it includes the scary word "error."
That's not an error!  It's a message.

Nonetheless, it was partly to reduce the GUI-related bloat, which affects
correctness as well as generating nonsense messages, that I've switched
Tsukurimashou to use FontAnvil; and FontAnvil is a lot quieter.

I'd also support, though I doubt it'd be treated as a development priority
by other people involved, an effort to quiet down FontForge's output and
have it only write messages to stderr when they convey meaningful
information to the user.  This might include, for instance, having a
single master "verbose" flag and all debugging messages being conditional
on it.  I think FontForge actually includes several APIs for this already
("remove overlaps" contains one), but they are local to specific modules
instead of global; configurable only by modifying the code, instead of
from the command line; and set to "lots of verbose output" by default,
all of which should change.

I plan to have a global verbosity setting for FontAnvil at some point.
In the shorter term, I've been removing all debug output that is not
useful to ordinary users.

> using FontForge in script mode only, it must run without any errors.

Errors are not the same thing as messages.  Ideally it would run without
either, but I'd settle for running without *real errors*.

> developer releases a month – noone has the time to regularly check
> whether the created fonts are valid!  We *must* be able to rely that
> FontForge produces valud results.  For us, the 'old' FontForge release

By this standard, FontForge simply is not acceptable for production use.
You must check the results or else accept that they will sometimes be
wrong.  The idea that a script should be able to run without supervision
does not seem to be well accepted by the FontForge development team, who
tend to see scripts as time-savers for GUI users rather than as an end in
themselves.  See, for instance, this comment I got in 2013 when I
complained that no sequence of add extrema, remove overlap, and round
would produce consistently good results, even on fonts where SOME such
sequence would always be successful:

  "It is the sort of thing you have to do one glyph at a time. If you try
   to hit a whole font all at once, problems are bound to turn up."
  https://github.com/fontforge/fontforge/issues/473#issuecomment-15326244

That's fine if I'm doing it in a GUI by hand, but it excludes the
possibility of writing a generic "clean up font" script; and at the time,
nobody but me saw the fact that such operations couldn't really be
scripted as a meaningful problem.  Acceptance of scripting as important
has improved since 2013, but in mainline FontForge, that pretty much only
applies to Python scripting.

It was partly because FontForge is not, and probably never will be, really
trustworthy to run scripts without supervision, that FontAnvil exists at
all.  But my standard for trustworthiness is correct results, not an
absence of output to stderr.

> works, and recent versions produce errors, so it's easy to guess what

Again, errors are not the same thing as messages.  I think recent versions
are less likely to produce real errors, but no version is as reliable as I
wish it could be.

-- 
Matthew Skala
ms...@an...                 People before principles.
http://ansuz.sooke.bc.ca/