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
>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 int
Alexander Lakhin 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 "phras
27.04.2020 18:04, Tom Lane wrote:
> Alexander Lakhin writes:
>> 26.04.2020 22:13, Tom Lane wrote:
>> BTW, I tried to also use this markup inside the template for
>> , so we'd only need one font-switching special case not two.
>> Didn't work though --- apparently templates don't get applied recurs
Alexander Lakhin writes:
> 27.04.2020 18:04, Tom Lane wrote:
>> BTW, I tried to also use this markup inside the template for
>> , 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 templa
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 o
Peter Eisentraut 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 th
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 in
Peter Eisentraut 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 en
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
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 g
11 matches
Mail list logo
