Jeff Davis <pg...@j-davis.com> writes:
> Committed, thank you.
This commit has given the PDF docs build some indigestion:
Making portrait pages on A4 paper (210mmx297mm)
/home/postgres/bin/fop -fo postgres-A4.fo -pdf postgres-A4.pdf
[WARN] FOUserAgent - Font "Symbol,normal,700" not found. Substituting with
"Symbol,normal,400".
[WARN] FOUserAgent - Font "ZapfDingbats,normal,700" not found. Substituting
with "ZapfDingbats,normal,400".
[WARN] FOUserAgent - Hyphenation pattern not found. URI: en.
[WARN] FOUserAgent - The contents of fo:block line 1 exceed the available area
in the inline-progression direction by 3531 millipoints. (See position
55117:2388)
[WARN] FOUserAgent - The contents of fo:block line 1 exceed the available area
in the inline-progression direction by 1871 millipoints. (See position
55117:12998)
[WARN] FOUserAgent - Glyph "?" (0x323, dotbelowcmb) not available in font
"Courier".
[WARN] FOUserAgent - Glyph "?" (0x302, circumflexcmb) not available in font
"Courier".
[WARN] FOUserAgent - The contents of fo:block line 12 exceed the available area
in the inline-progression direction by 20182 millipoints. (See position
55172:188)
[WARN] FOUserAgent - The contents of fo:block line 10 exceed the available area
in the inline-progression direction by 17682 millipoints. (See position
55172:188)
[WARN] FOUserAgent - Glyph "?" (0x142, lslash) not available in font
"Times-Roman".
[WARN] PropertyMaker - span="inherit" on fo:block, but no explicit value found
on the parent FO.
(The first three and last one warnings are things we've been living
with, but the ones between are new.)
The first two "exceed the available area" complaints are in the "ICU
Collation Levels" table. We can silence them by providing some column
width hints to make the "Description" column a tad wider than the rest,
as in the proposed patch attached. The other two, as well as the first
two glyph-not-available complaints, are caused by this bit:
Full normalization is important in some cases, such as when
multiple accents are applied to a single character. For instance,
<literal>'ệ'</literal> can be composed of code points
<literal>U&'\0065\0323\0302'</literal> or
<literal>U&'\0065\0302\0323'</literal>. With full normalization
on, these code point sequences are treated as equal; otherwise they
are unequal.
which renders just abysmally (see attached screen shot), and even in HTML
where it's rendering about as intended, it really is an unintelligible
example. Few people are going to understand that the circumflex and the
dot-below are separately applied accents. How about we drop the explicit
example and write something like
Full normalization allows code point sequences such as
characters with multiple accent marks applied in different
orders to be seen as equal.
?
(The last missing-glyph complaint is evidently from the release notes;
I'll bug Bruce about that separately.)
regards, tom lane
diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml
index 9db14649aa..96a23bf530 100644
--- a/doc/src/sgml/charset.sgml
+++ b/doc/src/sgml/charset.sgml
@@ -1140,6 +1140,14 @@ SELECT 'w;x*y-z' = 'wxyz' COLLATE num_ignore_punct; -- true
<table id="icu-collation-levels">
<title>ICU Collation Levels</title>
<tgroup cols="8">
+ <colspec colname="col1" colwidth="1*"/>
+ <colspec colname="col2" colwidth="1.25*"/>
+ <colspec colname="col3" colwidth="1*"/>
+ <colspec colname="col4" colwidth="1*"/>
+ <colspec colname="col5" colwidth="1*"/>
+ <colspec colname="col6" colwidth="1*"/>
+ <colspec colname="col7" colwidth="1*"/>
+ <colspec colname="col8" colwidth="1*"/>
<thead>
<row>
<entry>Level</entry>
