Improving using custom ouputter

[Omikhleia]

It's not possible to add a new outputter easily. I experimented writing a few custom outputters¹, but the backend choices are hard-coded in SILE.init() and heavily tied to picking a shaper.

sile/core/sile.lua

Lines 118 to 135 in b5ce8e6

	if not SILE.backend then
	SILE.backend = "libtexpdf"
	end
	if SILE.backend == "libtexpdf" then
	SILE.shaper = SILE.shapers.harfbuzz()
	SILE.outputter = SILE.outputters.libtexpdf()
	elseif SILE.backend == "cairo" then
	SILE.shaper = SILE.shapers.pango()
	SILE.outputter = SILE.outputters.cairo()
	elseif SILE.backend == "debug" then
	SILE.shaper = SILE.shapers.harfbuzz()
	SILE.outputter = SILE.outputters.debug()
	elseif SILE.backend == "text" then
	SILE.shaper = SILE.shapers.harfbuzz()
	SILE.outputter = SILE.outputters.text()
	elseif SILE.backend == "dummy" then
	SILE.shaper = SILE.shapers.harfbuzz()
	SILE.outputter = SILE.outputters.dummy()

Say I have my "dual" typesetter, the consequence of the above is that sile ... -b dual doesn't work (the outputter is nil)...

Obviously, sile ... -u outputters.dual doesn't work either (the shaper is nil)...

What does work is sile ... -u outputters.dual -u shapers.harfbuzz but it does seem a bit awkward: if the outputter is chosen so soon, shouldn't it be responsible for requiring the only shaper it supports?

Anyhow;

• The discrepancy between -b xxx and -u outputters.xxx -u shapers.yyy us dubious at best, this could call for some refactor
• Or the working solution with -u outputters.xxx -u shapers.yyy could call for being documented and explained
• (I suppose we'd eventually want outputters to be shaper-agnostic, but we don't build/ship SILE with the pango shaper, so defaulting to harfbuzz could be acceptable in most cases?)

Footnotes

1. One for 2-up pages, one for HTML, and a "dual" acting as a proxy to simultaneously delegate to the PDF and debug outputters ('cause I was tired to have to do two runs in -b debug and (implicitly) -b libtexpdf, so why not try to craft an outputter for the fun of triggering both, and possibly even add its own mess around them, such as doing some extras... :p) ↩

[Omikhleia]

Other notes in passing, from my experimental HTML and "dual/proxy" outputters.

An outputter being at the end of the chain, it should not have "getters" accessed from outside, that's a separation of concern matter.

Regarding the outputter API, thus:

• Method outputter.getCursor () should not be listed in the base (abstract) outputter, and should be private (only used inside the ouputters that need it to be implemented that way, but it's their own business).
• Likewise, method outputter:getOutputFilename should not be listed in the base (abstract) outputter either, and should be made private.
• Method outputter.getImageSize() (used by the image package) should also not be outputter dependent.
  While the default implement relies on libtexpdf is a thing, but it's unrelated to outputters by definition.
• Outputters should not use SILE.documentState, that's a dirty inversion of logic.
  The base class (likely) should call the outputter API with the necessary information when it does have it, rather the the outputter accessing some global variables.
• Erroneous code, we have outputter:startLink in the libtexpdf outputter while it should be beginLink (as in the base class and as used by the pdf package). We are just lucky pdf.annotation seems to do nothing currently...
• outputter:startLink has destination, options as argument, it should also have x0, y0 coordinates.
  Rationale: while PDF uses (x0, y0, x1, y1) at the end of the link, other ouputters might need the initial position since the start of the link. (Typically, HTML could use these to style an <a> with an absolute position on link entry, whereas it's too late at the </a> on link exit)

[Omikhleia]

Also (from a previous code quality review I had forgotten)

• outputter.drawSVG is ill-named, it expects a PDF graphics path construct.