Quote:
Originally Posted by jackie_w
 Is there something I'm not understanding ?
Let me outline my own problem with the current pipcat-plus-makepatch method which adds an unreadable, untweakable blackbox hexcode patch to GeoffR's nickel.patch file.
A hypothetical new patch...
I make a patch to a CSS stream which changes the GUI booklist Title to the Avenir font in bold and not italic. It will probably require me to also change the font-size. I use makepatch and publish it.
Everybody loves it ( I did say this was hypothetical) or rather the idea of it, except
... I'd like to use Bookerly, not bold, at a different font-size
... no, I like the new bold but I preferred the old Georgia
... no, I want Bookerly italic
... etc etc
How many makepatch's do I need to create to make everyone happy?
What is desirable for a new approach to patching zlib CSS would be the ability to patch a zlib in the same way that the nozlib `Custom reading footer style` patch allows, i.e. the user can tweak one or more variables all for the same CSS stream.
Other opinions are also available... |
That's actually a great idea.
I'll probably add a config instruction where users can set variables and they can be substituted into any other instruction. What do all of you think of that?