groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build, BuildFoundries, and gropdf changes coming


From: Deri
Subject: Re: build, BuildFoundries, and gropdf changes coming
Date: Fri, 11 Nov 2022 17:04:32 +0000

On Thursday, 10 November 2022 22:04:04 GMT G. Branden Robinson wrote:
> Hi all,
> 
> As alluded to in my last message to Alex...
> 
> Deri's improvement of gropdf's font file resolution procedure for
> embedded fonts[1] has pulled on a loose thread and is having interesting
> results.
> 
> Here are some selected commits from my working copy.  The creation of
> the compiled groff man pages as a PDF document is proving to be an
> effective integration test.  I foresee a future where the
> "BuildFoundries" script does less work.  We're pretty much stuck with an
> approach like the below because to do otherwise would mean recursively
> applying groff-font-path-enabled lookups on file specifications
> appearing inside the "download" file.[2]  That seems to me (1) to
> promise even more complexity and (2) to abuse the semantics of the groff
> font path, which is to _locate groff font and device description files_.
> Not to locate Type 1 font files that the formatter itself cares nothing
> about.  (One day, we might change groff to load and interpret Type 1 and
> OpenType fonts itself.  That day has not yet come.)
> 
> Maybe a "-D type1-dir" option for gropdf, which means "look HERE, I MEAN
> IT" for embeddable fonts would be worth implementing for the sake of our
> users, who may understandably be frustrated with all this download file
> business?  Maybe we can see how much such frustration arises from
> 1.23.0.rc2 before resorting to this.

Hi Branden,

This might be one of your "thinkos". :-)

It is not a very good idea. The URW fonts, packaged or (sometimes) delivered 
with ghostscript, have various nom-de-plumes all of which require checking - 
this is what BuildFoundries does. There is no way of knowing whether the 
directory pointed to by -D contains identical metrics to when the groff fonts 
were created by afmtodit. In addition, sometimes the required .afm files are 
in a separate directory, which BuildFoundries also searches. I don't see the 
point of duplicating BuildFoundries code within gropdf, but without it you 
would only do half the job.

Please can you elaborate on what you mean by "this download business". As far 
as I know there have been two separate reasons for missing fonts:-

A) During groff builds gropdf could pick up an "old" download file. This 
happened because gropdf would favour the last matching entry and the build 
font directory would be passed as the first location, so if either the site-
fonts or the system fonts directories contain stale entries, these were 
favoured. This is no longer a problem because gropdf now favours the first 
valid entry, so the entries in the shiny new build font directory (just 
created by BuildFoundries) are used.

B) After groff installation the entries in the the system font directory can 
go stale if a new version of ghostscript or urw-fonts package is installed, 
with different directory structure or filenames. The simple solution to this 
is to re-run BuildFoundries which would correct stale download file. At least, 
this used to be the method, but BuildFoundries was removed from the list of 
executables installed in the bin directory. So, perhaps the kindest thing for 
users, is to reinstate BuildFoundries as a tool and perhaps reference it when 
gropdf finds the file is missing.

Is there something I am missing regarding "download business"? What is the 
solution to (B), it certainly is not passing a -D flag.

> There are some wordos in the following.  This is what my commit messages
> look like before they spend a few days percolating and I push them 30-50
> at a time.
> 
> commit f30d2062465ccb05162859774d5a179e10dabcf6
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Tue Nov 8 19:26:24 2022 -0600
> 
>     [gropdf]: Tweak diagnostic message.
> 
>     * src/devices/gropdf/gropdf.pl (LoadFont): Tweak diagnostic message.
>       Include invalid file specification about which we are complaining.
>       This makes the message pretty long, sadly, but it should steer the
>       reader directly to the problem while requiring only the vaguest
>       understanding of what the "download" file is for.  Also: don't start
>       message clause with a capital letter {per GNU Coding Standards};
>       double quote file name references; and move parenthesized groff font
>       name outside of single quotes.
> 
> commit 48586545e0261a030e577ce163f9aa7003e6d8e8
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Tue Nov 8 19:27:45 2022 -0600
> 
>     src/devices/gropdf/gropdf.pl: Fix whitespace nits.
> 
>     This is shut up Git from howling as follows.
> 
>     <stdin>:27: space before tab in indent.
>     [...and so forth...]
>     warning: squelched 2 whitespace errors
>     warning: 7 lines add whitespace errors.
> 
> commit c99d97342849837cf7648861e6ac618cf9c97a93
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Mon Nov 7 06:59:53 2022 -0600
> 
>     INSTALL.extra: Revise.
> 
>     * Place "URW fonts" discussion into its own subsection due to length.
>     * Clarify that "test-groff" has to be run from the build directory.
> 
> commit 496c627c4656be4e5ab7e1de36e82742d7131344
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Wed Nov 9 02:11:34 2022 -0600
> 
>     doc/doc.am: Add commentary and tweak code style.
> 
>     * doc/doc.am (doc/groff-man-pages.pdf): Add explanatory comment.
>       Rearrange options to put prepreprocessor stuff first, formatter
>       options next, and postprocessor options last.
> 
> commit caff5c9e92fbecbd2ccff413a1cb0456a879f8c9
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Wed Nov 9 08:24:52 2022 -0600
> 
>     [devpdf]: Tweak generation of "download" file.
> 
>     * font/devpdf/devpdf.am (font/devpdf/download): Improve
>       comprehensibility of comments in generated "download" file.  Stop
>       bracketing path element separator with spaces.
> 
We have been here before, it used to matter, look at the output of gs -h, you 
will see space bracketed delimiters. I think I made a change to accept with/
without, can't remember.

> commit 0d4220f2bdcba5a448c8396ba3081cb2fb817836
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Wed Nov 9 09:02:52 2022 -0600
> 
>     [afmtodit]: Handle fatal exits more idiomatically.
> 
>     * src/utils/afmtodit/afmtodit.pl: Use our own fatal exit function
>       instead of Perl's "die".
> 
>       (croak): New subroutine emits argument as part of diagnostic message
>       exits with status 1.
> 
>       (usage): Exit with status 2, not 1, on usage errors.
> 
> commit c23668e797ba4ace62536a0f5b9ead6307361680
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Wed Nov 9 09:31:25 2022 -0600
> 
>     [afmtodit]: Implement new '-w' option.
> 
>     * src/utils/afmtodit/afmtodit.pl: Add new command-line option to specify
> the generated font description's "spacewidth" parameter; in commit
> bf7f6862c3, 2021-09-24, I made libgroff complain if this directive is
> missing (since any font, even a "special" one can be selected as current
> and the formatter and the behavior's behavior when
>       encountering an input space should be well-defined under that
>       circumstance).  Adding this option enables a well-formed font
>       description to be produced.
> 
>     * src/utils/afmtodit/afmtodit.pl (usage):
>     * src/utils/afmtodit/afmtodit.1.man (Synopsis, Options): Document it.
> 
>     * NEWS: Add item.
> 
> commit b8b75b176365695ca380362a725a721081828a2e (HEAD -> master)
> Author: G. Branden Robinson <g.branden.robinson@gmail.com>
> Date:   Wed Nov 9 10:28:32 2022 -0600
> 
>     [devpdf]: Do more explicit work and less magic.
> 
>     * font/devpdf/devpdf.am (devpdffont_DATA): Add all of the PostScript
>       Level 2 base 35 font descriptions (from the default foundry).  Also
>       add the "EURO" font description file and the "FreeEuro" PFA and AFM
>       files, making these explicit targets and dependencies.
> 
>       (devpdffont_DATA) [HAVE_URW_FONTS]: Also add the URW foundry's version
> of the base 35 fonts.
> 
>       (font/devpdf/freeeuro.afm): Add new target, a simple file copy from
>       the devps font directory.
> 
>       (font/devpdf/EURO): Generate font description file from the devps font
> directory.
> 
>       (font/devpdf/freeeuro.pfa): Add new target, a simple file copy from
>       the devps font directory.
> 
>       (MOSTLYCLEANFILES): Clean freeeuro.{afm,pfa}.

Why duplicate freeeuro.{afm,pfa} from devps?

> Regards,
> Branden
> 
> [1]
> https://git.savannah.gnu.org/cgit/groff.git/commit/?id=7e5d433ba5ddc2389986
> a5c02f91eb57fc1de47d
> 
> [2] The FreeEuro font file is cheekily located at
>     "../devps/freeeuro.pfa", which is nicely robust for a groff _build_
>     but pretty dubious for installation.

I don't understand this. Why is it cheeky, looks like a normal relative path 
to me? Why is it dubious for installation? You may have missed that gropdf 
converts all relative paths to an absolute path while reading download files.

Cheers 

Deri







reply via email to

[Prev in Thread] Current Thread [Next in Thread]