Update of bug #68500 (group groff):
Status: None => Need Info
Assigned to: None => barx
_______________________________________________________
Follow-up Comment #4:
[comment #3 comment #3:]
> [comment #2 comment #2:]
>> You want to add _yet another_ so that we can make a _build-time_
>> decision regarding whether we inject 3 Texinfo commands?
>
> No, I want the build to not fail just because the system lacks a package
> whose sole purpose is to make a prettier version of a diagram that can (and
> has for a long time) be presented another way.
Would depending on GNU _plotutils_ instead, and using _pic2plot_(1) to
generate an SVG instead of a PNG for use in the HTML version of our Texinfo
manual) be an improvement in your opinion?
$ dpkg -s imagemagick-6.q16 | sed -n '1,/^Description:/p'
Package: imagemagick-6.q16
Status: install ok installed
Priority: optional
Section: graphics
Installed-Size: 663
Maintainer: ImageMagick Packaging Team
<[email protected]>
Architecture: amd64
Multi-Arch: foreign
Source: imagemagick
Version: 8:6.9.11.60+dfsg-1.3+deb11u14
Replaces: imagemagick (<< 8:6.9.2.10+dfsg-2~)
Provides: imagemagick, imagemagick-6.defaultquantum
Depends: libc6 (>= 2.4), libmagickcore-6.q16-6 (>= 8:6.9.10.2),
libmagickwand-6.q16-6 (>= 8:6.9.10.2), hicolor-icon-theme
Recommends: libmagickcore-6.q16-6-extra, ghostscript, netpbm
Suggests: imagemagick-doc, autotrace, cups-bsd | lpr | lprng, curl, enscript,
ffmpeg, gimp, gnuplot, grads, graphviz, groff-base, hp2xx, html2ps,
libwmf-bin, mplayer, povray, radiance, sane-utils, texlive-base-bin, transfig,
ufraw-batch, xdg-utils
Breaks: libmagickcore-dev (<< 8:6.9.2.10+dfsg-2~)
Description: image manipulation programs -- quantum depth Q16
$ dpkg -s plotutils | sed -n '1,/^Description:/p'
Package: plotutils
Status: install ok installed
Priority: optional
Section: math
Installed-Size: 1069
Maintainer: Andreas Metzler <[email protected]>
Architecture: amd64
Multi-Arch: foreign
Version: 2.6-11
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libplot2c2 (>= 2.6), libstdc++6
(>= 5)
Suggests: gsfonts
Description: GNU plotutils command line tools based on libplot
$ dpkg -s libplot2c2 | sed -n '1,/^Description:/p'
Package: libplot2c2
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 2980
Maintainer: Andreas Metzler <[email protected]>
Architecture: amd64
Multi-Arch: same
Source: plotutils
Version: 2.6-11
Replaces: libplot, libplot2, plotutils (<< 2.4.1)
Depends: libc6 (>= 2.29), libgcc-s1 (>= 3.0), libpng16-16 (>= 1.6.2-1),
libstdc++6 (>= 5), libx11-6, libxaw7, libxext6, libxt6
Conflicts: libplot, libplot2
Description: GNU plotutils libraries
>> A person building from the repo should be expected to know
>> how to drive a package manager.
>
> Yes. Similarly, a person building from the repo shouldn't be required to
> install a package just to achieve some cosmetic icing for seven lines out of
> the tens of thousands in the manual.
I expect to add further images, likely exhibits of _groff_ output as rendered
to PostScript or PDF.
...which, admittedly, will probably resurrect the dependency on ImageMagick.
I guess I have to disclose one of my Evil Plans(tm) at this point.
It's to please **you**. As the record elsewhere records, you don't like our
Texinfo manual elevati _ms_(7) above other full-service macro packages by
presenting it, and only it, in detail. (And, to be fair, I tire of
maintaining _three_ copies of its documentation: "doc/groff.texi.in",
"doc/ms.ms.in", and "tmac/groff_ms_7.man"). But I've been reluctant to remove
it because I've lacked any other example of full-service package usage
concrete enough to suit the needs of learners who have a harder time reasoning
from the abstractions presented in the preceding "Tutorial for Macro Package
Users" chapter.
So my idea was, well, why not take a sample document, like a basic business
letter, and show how to compose it in _each_ of our full-service macro
packages _me_, _mm_, _mom_, and _ms_. _groff_ input goes on the verso page,
and a rasterized image of the full page rendering on the facing recto page.
Then illustrate a basic man page in _man_ and _mdoc_ the same way.
Thus, our new Chapter 4.
> The new diagram is nice, but it's not so nice it should erect a new hoop to
> jump through just to get a successful build, _especially_ when we have a
> simple alternative rendering that communicates the same information.
I expect the cost/benefit ratio to improve over time.
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?68500>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc
Description: PGP signature
