Обсуждение: Rendering pi more nicely in PDF
In the department of nitpickery ...
"π" renders poorly in our PDF docs: as shown in the attached
screenshot, it doesn't line up on the baseline. I realized that
this is the same problem I'd run into recently with right-arrow,
and it can be solved in the same way, namely we have to specify
use of the symbol font explicitly. So attached is a proposed
patch to fix it.
Use of a new processing-instruction might not be the most elegant
way to do this ... anyone have a better suggestion?
(BTW, I tried to use "π" in the stylesheet files and it
didn't work; apparently that entity isn't loaded yet.)
regards, tom lane
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b0afaeb..fdbd4a0 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -1365,7 +1365,7 @@ repeat('Pg', 4) <returnvalue>PgPgPgPg</returnvalue>
<function>pi</function> ( )
<returnvalue>double precision</returnvalue>
<?br?>
- Approximate value of π
+ Approximate value of <?pi?>
<?br?>
<literal>pi()</literal>
<returnvalue>3.141592653589793</returnvalue>
diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index 58a2aa3..01bec32 100644
--- a/doc/src/sgml/ref/pgbench.sgml
+++ b/doc/src/sgml/ref/pgbench.sgml
@@ -1528,7 +1528,7 @@ SELECT 4 AS four \; SELECT 5 AS five \aset
<row>
<entry><literal><function>pi()</function></literal></entry>
<entry>double</entry>
- <entry>value of the constant PI</entry>
+ <entry>value of the constant <?pi?></entry>
<entry><literal>pi()</literal></entry>
<entry><literal>3.14159265358979323846</literal></entry>
</row>
diff --git a/doc/src/sgml/stylesheet-common.xsl b/doc/src/sgml/stylesheet-common.xsl
index b772f87..c9a9181 100644
--- a/doc/src/sgml/stylesheet-common.xsl
+++ b/doc/src/sgml/stylesheet-common.xsl
@@ -108,4 +108,8 @@
<br/>
</xsl:template>
+<!-- Support for generating pi symbol -->
+
+<xsl:template match="processing-instruction('pi')">π</xsl:template>
+
</xsl:stylesheet>
diff --git a/doc/src/sgml/stylesheet-fo.xsl b/doc/src/sgml/stylesheet-fo.xsl
index 6797e06..7bfc819 100644
--- a/doc/src/sgml/stylesheet-fo.xsl
+++ b/doc/src/sgml/stylesheet-fo.xsl
@@ -101,6 +101,11 @@
<fo:block/>
</xsl:template>
+<!-- overrides stylesheet-common.xsl -->
+<xsl:template match="processing-instruction('pi')">
+ <fo:inline font-family="{$symbol.font.family}">π</fo:inline>
+</xsl:template>
+
<!-- bug fix from <https://sourceforge.net/p/docbook/bugs/1360/#831b> -->
<xsl:template match="varlistentry/term" mode="xref-to">
Вложения
From the symbolic unit of the department... Hello Tom, 26.04.2020 22:13, Tom Lane wrote: > In the department of nitpickery ... > > "π" renders poorly in our PDF docs: as shown in the attached > screenshot, it doesn't line up on the baseline. I realized that > this is the same problem I'd run into recently with right-arrow, > and it can be solved in the same way, namely we have to specify > use of the symbol font explicitly. So attached is a proposed > patch to fix it. > > Use of a new processing-instruction might not be the most elegant > way to do this ... anyone have a better suggestion? I would use the phrase tag, which is intended for such uses: [1] [2]. The "phrase" sounds too generic, but it doesn't require yet another processing instruction e.g. for ∑ or a similar entity. [1] http://www.sagehill.net/docbookxsl/CustomInlines.html [2] https://tdg.docbook.org/tdg/4.5/phrase.html Best regards, Alexander
Вложения
Alexander Lakhin <exclusion@gmail.com> writes:
> 26.04.2020 22:13, Tom Lane wrote:
>> Use of a new processing-instruction might not be the most elegant
>> way to do this ... anyone have a better suggestion?
> I would use the phrase tag, which is intended for such uses: [1] [2].
Good idea, done that way.
> The "phrase" sounds too generic, but it doesn't require yet another
> processing instruction e.g. for ∑ or a similar entity.
Yeah, lack of easy applicability to other cases was the main thing
bothering me about the processing-instruction fix.
BTW, I tried to also use this <phrase> markup inside the template for
<returnvalue>, so we'd only need one font-switching special case not two.
Didn't work though --- apparently templates don't get applied recursively?
Oh well.
regards, tom lane
27.04.2020 18:04, Tom Lane wrote: > Alexander Lakhin <exclusion@gmail.com> writes: >> 26.04.2020 22:13, Tom Lane wrote: >> BTW, I tried to also use this <phrase> markup inside the template for >> <returnvalue>, so we'd only need one font-switching special case not two. >> Didn't work though --- apparently templates don't get applied recursively? >> Oh well. We can have a single template "symbol_font" and reuse it, but it doesn't seem cleaner to me (for just two cases). (Placing <phrase ...> into <xsl:template match="returnvalue"> wouldn't work as such a content goes into the output, whilst all xsl:templates apply to the input tree.) Best regards, Alexander
Вложения
Alexander Lakhin <exclusion@gmail.com> writes:
> 27.04.2020 18:04, Tom Lane wrote:
>> BTW, I tried to also use this <phrase> markup inside the template for
>> <returnvalue>, so we'd only need one font-switching special case not two.
>> Didn't work though --- apparently templates don't get applied recursively?
> We can have a single template "symbol_font" and reuse it, but it doesn't
> seem cleaner to me (for just two cases).
Yeah, I agree, that's not an improvement. It's invoking the template
two different ways, which seems pretty weird (at least to an XSL novice
like me).
regards, tom lane
On 2020-04-26 21:13, Tom Lane wrote: > "π" renders poorly in our PDF docs: as shown in the attached > screenshot, it doesn't line up on the baseline. I realized that > this is the same problem I'd run into recently with right-arrow, > and it can be solved in the same way, namely we have to specify > use of the symbol font explicitly. So attached is a proposed > patch to fix it. The real problem here is that the default font (Times or Times New Roman) embedded in PDF readers doesn't have these off-the-beaten-path glyphs. I'm surprised you see anything at all. The fix is to use a different font with more glyphs. I looked into that some time ago because this also effects the contributors list in the release notes, which has to be dumbed down because of this. To use a different font, you have to (a) pick one, and (b) install it locally when you build the PDFs. My proposal is to use the DejaVu fonts, which are open source and easily available for common operating systems. (Arguably, they also give the documentation a slightly fresher look.) The attached patch implements this. You just have to install the fonts somehow. Red Hat and Debian should have packages for this. We should write instructions for this in any case. (With this you can undo the other patches discussed here and just write π and it should look correctly.) -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-04-26 21:13, Tom Lane wrote:
>> "π" renders poorly in our PDF docs: as shown in the attached
>> screenshot, it doesn't line up on the baseline.
> The real problem here is that the default font (Times or Times New
> Roman) embedded in PDF readers doesn't have these off-the-beaten-path
> glyphs. I'm surprised you see anything at all.
Well, I do ...
> My proposal is to use the DejaVu fonts, which are open source and easily
> available for common operating systems. (Arguably, they also give the
> documentation a slightly fresher look.)
> The attached patch implements this. You just have to install the fonts
> somehow. Red Hat and Debian should have packages for this. We should
> write instructions for this in any case.
I think making the built documentation depend on nonstandard fonts
is a truly awful idea. It'd be okay perhaps if the requirement only
applied to people building the docs, but won't the requirement also
flow through to end users?
regards, tom lane
On 2020-04-29 21:58, Tom Lane wrote: > I think making the built documentation depend on nonstandard fonts > is a truly awful idea. It'd be okay perhaps if the requirement only > applied to people building the docs, but won't the requirement also > flow through to end users? No, the font is embedded into the built PDF. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-04-29 21:58, Tom Lane wrote:
>> I think making the built documentation depend on nonstandard fonts
>> is a truly awful idea. It'd be okay perhaps if the requirement only
>> applied to people building the docs, but won't the requirement also
>> flow through to end users?
> No, the font is embedded into the built PDF.
Ah. Well, if it doesn't enlarge the file very much, I guess that'd
be fine.
regards, tom lane
On 2020-Apr-29, Peter Eisentraut wrote:
> To use a different font, you have to (a) pick one, and (b) install it
> locally when you build the PDFs.
>
> My proposal is to use the DejaVu fonts, which are open source and easily
> available for common operating systems. (Arguably, they also give the
> documentation a slightly fresher look.)
>
> The attached patch implements this. You just have to install the fonts
> somehow. Red Hat and Debian should have packages for this. We should write
> instructions for this in any case.
It's not easy to build the PDF with this. There's a stray > in fop.xml.
After fixing that, I get a warning about fontbox java lib not being installed.
OK, I can install libfontbox-java and that one disappears. Then there's
this other warning:
[warning] /usr/bin/fop: JVM flavor 'sun' not understood
which seems to be innocuous. The build it still dies because of a CFF
type1 something or other:
Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/fontbox/cff/CFFType1Font
at org.apache.fop.fonts.truetype.OTFFile.isType1(OTFFile.java:151)
After a quick search I found this bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584472
which suggests that I patch /usr/bin/fop to find_jars in "fontbox2"
instead of fontbox. OK, remove package libfontbox-java, patch the
script, try again. Now it seems to work, and the doc looks pretty.
But apparently it's not sufficient -- the new font is not used
everywhere. For example footnotes seem to use a different font than the
main body of text. (I altered the fontname to Gentium, which I like
better, and uses a different glyph for "g" which is easy to spot ... and
notably absent in footnote in page 5 under 1.4 Accessing a Database.)
I +1 the idea of using a more complete font if it means we can render
contributor names better, though :-)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello hackers, 30.04.2020 00:23, Alvaro Herrera wrote: > But apparently it's not sufficient -- the new font is not used > everywhere. For example footnotes seem to use a different font than the > main body of text. (I altered the fontname to Gentium, which I like > better, and uses a different glyph for "g" which is easy to spot ... and > notably absent in footnote in page 5 under 1.4 Accessing a Database.) > > I +1 the idea of using a more complete font if it means we can render > contributor names better, though :-) We at Postgres Pro use the attached fop-config.xml (passed to fop as "-c .../fop-config.xml"). Please try it and see, whether the glyphs rendered as expected. You can also look at the generated pdf: https://postgrespro.com/media/docs/postgresql/12/en/postgres-A4.pdf But π (pi) is still rendered unusual as you can see on the page 179, so I would prefer the symbol font anyway. Best regards, Alexander