Follow-up Comment #33, bug #67207 (group groff): Resuming the conversation about build infrastructure stuff.
Deri responded to me in an email:
>> (font/devpdf/download): Set write permission on the target to work
>> around GNU Automake "distcheck" feature that makes make(1)-generated
>> files read-only; however we want "BuildFoundries" to rewrite the file
>> in place.
>
> A while ago you changed it from writing download directly to > > writing to
> download.tmp which
> is then "mv"ed.
I _think_ what's happening--but I haven't verified this or dug into Automake
internals to try to grasp what's going on--is that because "BuildFoundries.pl"
rewrites the "download" file by "clobbering" it, that triggers the overwrite
warning due to the permissions Automake sets to test the distribution
archive.
We use the "mv $@.tmp $@" technique in other places without provoking this
issue, at any rate, so the foregoing is my guess.
>> Since the PDF device doesn't need the "ZDR" font at all, I suggest making
>> the font mounting positions "line up" between the two output devices. So
>> like this.
>>
>>
>> -fonts 9 0 0 0 0 0 0 SS S ZD
>> +fonts 8 0 0 0 0 0 SS S ZD
> Yes, why not. I was trying to get ps and pdf to allocate similar mount
> positions, i.e.:-
> echo \\f[AB]Deri | test-groff -T[ps|pdf] -Z
> both produce:-
> x font 14 AB
> but never worked. Although:-
> fonts 9 0 0 0 0 0 SS S ZD S
> does. But that is so naughty and cheating, we should never do that!
> (something to keep in my back pocket when comparing grout between ps/pdf,
> useful for testing changes to pdf.tmac not introducing text positional
> changes.
Okay. Adding this change as a plan for this ticket.
>> I'd like to add an annotation to this comment header indicating that the
>> file is manually maintained, and to explain why. I'd probably copy the
>> same wording I used in the ChangeLog entry, but if you'd like to propose
>> some language, I'd be eager to see it.
>>
> Good idea. I may add a flag to afmtodit "--scale 0.89" so we can generate a
> pucker SS. Wording is pucker.
Okay. Adding this change as a plan for this ticket.
>> I'd like to get rid of the side effect of this target, and add a real one
>> for "StandardSymSL.pfa", which we'd generate in the build tree from
>> "StandardSymSL.pfb" using our own _pfbtops_(1) program. I piloted this in
>> bug #67207 and it passed a smoke test, at least.
> Yes it could be a separate target, but I would prefer a pfb file (more
> compact, gropdf is slow enough already). So maybe StandardSymSL.pfb.in
> generates (cp -u) StandardSymSL.pfb.
> SS does not actually need a separate rule, a change to foundry.in could take
> care of it, but if you intend to retire BuildFoundries transferring all the
> logic to devpdf.am it is probably not worth it.
Okay. Adding the low-hanging fruit as a plan for this ticket.
I don't have any short-term aim to retire "BuildFoundries.pl", but for
build-related jiggery-pokery I'd like to do as much in _make_(1) targets as
possible.
By contrast, we can still use _pfbtops_ to generate a PFA from
"StandardSymSL.pfb", but we don't have to name the PFA in the "download" file.
Not doing so makes the exercise a bit of a digression from "devpdf.am"'s
mission, but I like the idea of shipping the font in both formats, and I
strongly like the idea of actually exercising _pfbtops_'s code.
>> As previewed in bug #67207, I'd prefer to migrate to a statically populated
>> macro listing "ps" device fonts we expect to support. As PostScript is now
>> a withdrawn and abandoned standard, I don't think we need to pursue maximum
>> flexibility here.
>>
> Much better, & font S can go back to where it belongs.
Okay. Adding this change as a plan for this ticket.
>> diff --git a/tmac/pdf.tmac b/tmac/pdf.tmac
>> index 98fa3ef0e..9571e0148 100644
>> --- a/tmac/pdf.tmac
>> +++ b/tmac/pdf.tmac
>> @@ -38,34 +38,6 @@
>> .de pdf:SS
>> . fchar \\$1 \\S'16'\\$1\\S'0'
>> ..
>>
>>
>> As previewed in bug #67207, I'd like to kill off this (undocumented) macro
>> definition too, since we no longer use it, and it is easy for a document
>> author to recreate if they desire it.
> Yes, an oversight by me.
Okay. Adding this change as a plan for this ticket.
> My first time attempt at using the bug-list email interface, so it probably
> won't work.
It did not work out well. You need to be sure to GPG-sign the reply with the
key in your Savannah profile, and anything you put below the "savane" line
that the reply interface says **has** to be there, it will discard from your
message.
I learned these things the hard way.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?67207>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
