Can a locale change the qandaset.label.length value?

[petterreinholdtsen]

Working on updating the nb and nn locale, I discovered that the default value of 2.5em for qandaset.label.length used by the fo stylesheets to set the provisional-distance-between-starts in the question and answer parts is to short to fit the translated strings. Is there a way to change this value in the nb.xml and nn.xml files? I would not want to create locale files that produce broken PDFs by default.

[bobstayton]

I understand the problem, but the gentext files are for generated text. They contain no instances of language-specific formatting tweaks. In general, formatting tweaks would need to take into account output format (html, fo). Since there is a stylesheet parameter that controls that width, that is easily customized to fix the problem. The question is how to communicate that to the users of the new locale files.

[petterreinholdtsen]

[Bob Stayton]

I understand the problem, but the gentext files are for generated text. They contain no instances of language-specific formatting tweaks. In general, formatting tweaks would need to take into account output format (html, fo). Since there is a stylesheet parameter that controls that width, that is easily customized to fix the problem. The question is how to communicate that to the users of the new locale files.

Right. With the FO putput, the text for Q&A lists for nb and nn end up with overlapping text, ie the text of the "front" cell on top of "body" cell. There is no such problem with the HTML output, as it do not hardcode the cell width. For the nb and nn locales to work by default, the width need to be increased.

For the record, dblatex do not hardcode the cell width in the Q&A output, which seem to work fine. Perhaps an idea also for the FO output.

-- Happy hacking Petter Reinholdtsen

[bobstayton]

I suspect dblatex can test the length of a typeset string and adjust the allotted width accordingly. That is something that XSL lacks, except in the context of tables with table-layout="auto" (which FOP still does not support). Even good old troff could do that!

[petterreinholdtsen]

[Bob Stayton]

I suspect dblatex can test the length of a typeset string and adjust the allotted width accordingly.

Probably. Latex is nice that way.

That is something that XSL lacks, except in the context of tables with table-layout="auto" (which FOP still does not support). Even good old troff could do that!

Yeah, many issues with the XSLT/FOP tool chain, but I hoped to be able to improve it at least a little bit. Would be sad to fix the nb and nn locales for non-FO output leaving FO output broken by default.

If the docbook locale system fail to provide the width setting and dynamic scaling of the width in fop is broken, what about increasing the default value from 2.5em to 4.5em? It would provide enough space for the Norwegian strings. 2.5em seem rather short in any case. This patch solve the case.

diff --git a/xsl/fo/qandaset.xsl b/xsl/fo/qandaset.xsl index ac6f89b5c..61e49d083 100644 --- a/xsl/fo/qandaset.xsl +++ b/xsl/fo/qandaset.xsl @@ -130,7 +130,7 @@

3em - 2.5em + 4.5em -- Happy hacking Petter Reinholdtsen

[petterreinholdtsen]

[Petter Reinholdtsen]

This patch solve the case.

diff --git a/xsl/fo/qandaset.xsl b/xsl/fo/qandaset.xsl index ac6f89b5c..61e49d083 100644 --- a/xsl/fo/qandaset.xsl +++ b/xsl/fo/qandaset.xsl @@ -130,7 +130,7 @@

3em - 2.5em + 4.5em

Given how the '2.5em' value in qandaset.xsl is a string, and your statement that locales only can provide strings, what about introducing a new string that can be set in locales? It would be the default width the question and answer strings for use by locales where two character widths is not enough. Something like this, perhaps:

Is that even possible with XSL? I lack the skills myself to do so, perhaps someone else can help make it happen?

-- Happy hacking Petter Reinholdtsen

[bobstayton]

Yes, it is possible to do this in XSL. The parameter body would be changed from a single value to instead contain a template call to "gentext" with that key. That would be executed at runtime to load the localized value. We have not done formatting features with gentext, but I imagine there could be other applications for this mechanism.

qanda.default.label.length Then the locale files would need to be updated to add a new template with that key. At first you would only need to add it to English (en.xml) and any others you want different, because the build process will fill in any missing templates for the other languages from en.xml.