search

sillsdev / ptx2pdf

XeTeX based macro package for typesetting USFM formatted (Paratext output) scripture files
23 stars 8 forks source link

Could user interface load custom but overrideable styles? #902

Open davidg-sil opened 1 year ago

davidg-sil commented 1 year ago

Updated suggestion

See comment below for rethought suggestion

Initial query

As I'm guessing to be the cause for #897, an entry in the manual stylesheet ptxprint-mods.sty overrides user interface settings. This can be a very helpful feature, (e.g. setting a sidebar parameter which isn't in the list of options), but it can then come back and be very confusing a few months later when a new feature becomes available in the UI.

It would be useful if the UI remembered a list of e.g. 'None|x-credit/fontsize' which was getting set by the stylesheet, and then marked them in grey or something like that, to indicate that setting them without commenting the line in ptxprint-mods.sty might not do anything.

Alternatively, if that value-by-value granularity gets too hard, then... perhaps some kind of reminder that some parts of the style gets overridden? Please?

mhosken commented 11 months ago

We don't read or touch ptxprint-mods.sty, so getting down to the granularity of which styles ptxprint-mods.sty may be messing with would be quite a bit of work. In short, people really shouldn't be using ptxprint-mods.sty unless they are willing to walk on coals. Would some visual reminder (Advanced flashing red or somesuch) that ptxprint-mods.sty is enabled, be of any use or does it have to be at the style level?

davidg-sil commented 11 months ago

My motivation is that sometimes ptxprint-mods.sty is the only way, e.g. non-symmetrical border-padding options, but it gets old as UI changes come on line and once its old, it breaks things...

With me now knowing where to update the list of CamelCase styles, then (assuming new things that the UI doesn't understand still get passed through unaltered), I'd like to suggest another pathway, where the getting old doesn't bite. (Hopefully it also ends up as a more minor patch). I've [Marked the code like this]

  1. A bit like shared/ptxprint/Conf/Changes.txt and (project-wide) PrintDraftChanges.txt, the custom.sty, we allow something like a shared/ptxprint/Conf/custom.sty file, which (just like PT's custom.sty), gets interpreted before the UI does its thing. [UI gets a new tick-box, and python model is (optionally) told to process yet another stylesheet just like the other 2 or 3 it's already loading]
  2. People wanting to make not-yet-in-the UI style changes get told to put them in their shared/ptxprint/Conf/custom.sty When the UI gets updated to enable editing those parameters, whatever's in that file is automatically overridden. [Documentation changes]
  3. A visual reminder that ptxprint-mods.sty is enabled, e.g. warning triangle on the style page and help page, with a hover text that says something like "shared/ptxprint/Conf/ptxprint-mods.sty is enabled, some style settings may be getting ignored. If you want those style choices to be controllable by the UI, put them in shared/ptxprint/Conf/custom.sty instead." [UI gets a new warning triangle]