Menu
▾
▴
1 Attachments
#5162 Some hooks useful for video production
Producing ps or pdf documents intended to be used as
a source for video production requires some changes to
the output at a very late stage.
Often a page needs to repeated more than once with only
changes to some kind of progress bar / line or changes
to the color of a few grobs.
Parts of this postprocessing might be passed to postscript,
parts of this postprocessing might be done in the dump-page
procedure.
Therefore this patch provides a hook to write arbitrary
code to the prolog section of postscript output and a
hook to take over the dump-page process.
Using rgb values < 0 and > 1 for grobs is an efficient
way to pass the information that, when and for how long
an object should change its color to a late state of
processing. Therefore a way to disable the range
check implemented in color? and to disable the precision
restriction in setrgbcolor is provided.
You are missing a Rietveld review allowing for commenting on the patch details. At any rate, I think this approach is far too ad-hoc. You'd not get it accepted in the Linux kernel (which you claim to be your metric). I rather propose that you instead allow color to be a list starting with a symbol.
Then you can set
color-function.film.ps = #(lambda (rest of list) ...)
to generate a string in the manner of "setcolor" in scm/output-ps.scm. You can then set your colors as (cons 'film rest of list), if necessary through a callback.
When color-function.film does not exist, a color of (film ...) will lead to an error message at override time. Otherwise, it may lead to an error message at output time (when there is no code for a particular backend).
This leads to useful extensibility, does not mess with the value checks (you'll just add more elements for your film color, depending on the particular application) and complains for a useful subset of undefined situations.
Well, not every simple solution is
I believe that KISS is still one of the most important principles.
It is evident that the proposed change to color? and setcolor cannot harm any existing code as lilyponds behaviour does not change unless overloaded-rgb? is set to #t.
It is also evident that the proposed change to dump-page cannot harm any existing code as lilyponds behaviour does not change unless use-ps-dump-page-replacement? is set to #t.
It's also quite obvious that the possibility to pass some code directly to the postscript prolog simply by string-appending it to ps-user-prolog is a usefull feature and does no harm. This feature might also be used for other purposes, e.g. watermarking and page decoration.
Yes. It would be possible to allow color to be either a list of three numbers in the range [0..1] or a list starting with some symbol followed by other values.
You state that this approach would lead to
I tend to believe that it is nothing but over-engineering.
Knut
Last edit: Knut Petersen 2017-07-26
Hidden functionality violating existing data checks and passing unrelated data through fields intended and document for something else working only for a single application and a single backend and requiring new surgery for every kind of similar requirement only meets the "stupid" moniker of KISS since it leads to ballooning code and requires every single person wanting to implement something new to submit their own patches to the core of LilyPond rather than being able to use existing hooks.
Of course you are right about my suggestion not covering supplemental preamble material: that could be naturally implemented in the same manner, again covering a number of backends and the needs for a lot of applications.
Passing postscript code to other backends indeed is a good idea ;-)
Yes. Every single person who wants to override code that cannot be overriden from within a score source might ask for a patch - but once implemented everybody can use that hook. Nobody will ask again.
So you agree that a hook mechanism discriminating between backends is a good idea. That's why I proposed it.
Well, it will save you or the next person this kind of discussion next time they want to implement something along that line. For example, you are only interested in the PostScript backend. Other people might want to try doing animated SVG and I don't see the point in having them start over.
These would be happy to have the possibility to use overloaded-rgb? and probably would need an extended svg dump-page. So they probably would ask for a predicate use-svg-dump-page-replacement? in videoextensions.scm and a test for that predicate in the dump-page procedure in framework-svg.scm.
I have to put this to review else I'll miss this for my countdown. However without any Rietveld the review is not going to be that detailed if no other dev bothers to apply the patch locally.
I can do that Rietveld for you but then I own the review and am the only one that can edit it, so it becomes tedious.
Can you upload this to Rietveld for code review Knut please?
I don't think that there will be an agreement with David, so uploading to Rietveld is probably pointless.
Setting this back to 'needs_work'