Hi Jan, Thanks for looking into this. Of the 3 options you propose, option (2) seems the most preferable.
Thanks, Chris On 22/02/2019 22:30, Jan Tosovsky wrote: > On 2019-02-20 Chris wrote: >> On 09/02/2019 18:25, Jan Tosovsky wrote: >>> there is a proposal to enhanced painting of table borders to avoid visual >>> inconsistencies in some renderers (Acrobat Reader, Chrome): >>> https://issues.apache.org/jira/browse/FOP-2536 >>> >>> That technique renders another set of shapes over the existing ones. Not >>> everyone wants this as a default behaviour. After applying the patch it can >>> be activated via RendererOption 'overpaint-table-borders'. It means it can >>> be set programmatically, but not via configuration file or cmdline options. >>> >>> I personally do not need this as a cmdline switch, but having this option in >>> the configuration file is IMHO a must for general audience. >>> >>> So the questions: >>> (1) option name (is boolean 'overpaint-table-borders' Ok or something else >>> should be prefered, e.g. 'table-border-rendering-mode' with the set of >>> String values, initially 'standard' and 'overpaint') >>> >>> (2) If cmdline switch would be useful, what the name should be used >>> >> 'table-border-rendering-mode' with the set of >> String values, initially 'standard' and 'overpaint' > Ok, thanks. > > I've implemented this option for PDF renderer only. After parsing the > configuration file this option is passed via RendererOptions map into the > TableLayoutManager where it controls if borders are overpainted or not. > > My intention was to write a layout test case. However, when layout test is > executed, the PDF renderer configuration is ignored as the MIME type is now > application/X-fop-intermediate-format, where this option is missing. > > So there are some options now: > (1) making this option global (like target-resolution) > (2) duplicating this option also for Intermediate renderer (AFAIK there is no > other option yet) > (3) accepting that the overpainting is not covered by any layout test > (enabling is on user own risk anyway) > > Thanks for your inputs, > > Jan > > > > . >
