Follow-up Comment #38, bug #63808 (project groff): [comment #37 comment #37:] > > Here's what I need to know. > > > A) Is it even valid to try to test gropdf with 'gs' available but "no URW fonts"? You explained in comment #7 that URW fonts were donated to Ghostscript. That they might be forked or separately maintained in variant forms is not strongly relevant, except for the file name and directory changes that have proven otherwise frustrating. > > Definitely. Although in debian the fonts associated with ghostscript are the same files as you would get if you installed the URW fonts as a separate package without ghostscript, in other linux distros such as the one I use, they are different versions. You can just install ghostscript and the fonts are available, without the relevent afm files, no symlinks. So anyone using a distro like mine who installs ghostscript (common) will be able to have standard gropdf. On your system (debian) if ghostscript is installed you will always get extended gropdf, so I understand your question, but we have to cater for distros which don't follow the debian way.
I agree. That leads to the question I didn't ask quite clearly... > Version could be relevant if glyph coverage is different. (Quite so.) > > B) If it is, what does that test scenario look like? > > As in comment #3, but I will update it to current nomenclature. > > if gs or urw > run check-default-foundry.sh > if urw > run check-urw-foundry.sh > end > end > > In both cases you are looking for the 35 groff fonts, and additionally EURO in the default foundry. If any are not found then the test fails. Then you are saying "urw absent, gs present" is _not_ a supported groff configuration scenario. The question I was trying to ask was, "how do I simulate the scenario of URW fonts being absent and Ghostscript being present on the Debian system I'm using for testing?" It sounds now like I actually did manage to do so with my brutal "let the symlinks dangle" technique. And moreover the tree as of commit https://git.savannah.gnu.org/cgit/groff.git/commit/?id=206dcc0806b4da9d9d197540f4fa3aa86274d28b did in fact produce the outcome from this scenario (and the other 3 states of urw, gs bits) that you anticipated. What was *not* clear to me at all was that you did not intend for "urw absent, gs present" to be a supported scenario. (If grubbing through "gs -h" output discovers URW fonts, or finding them in any other way succeeds, it doesn't fall within this configuration.) Meaning that we expect the automated test suite to fail in that case, and succeed in the other three. Somehow that criterion didn't percolate into my brain through the ~38 previous comments to the bug. I guess I did not say outright that I am only trying to explore the space of _supported_ groff configurations, which is plenty large enough. The space of unsupported configurations is not interesting to me except insofar as points in it arise in practice often enough to require documentation for our users. I will therefore revert the commit currently at HEAD. Can I then regard this issue as resolved? Will you join me in leaving what hairs remain on our scalps intact? ;-) _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?63808> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
