Attractively formatting Project Gutenberg texts
|
![]() |
GutenMark has no formal bug-tracking system (the level of community interest not having justified it as of yet), but here's a simple table which I'll use to record outstanding issues (including any you tell me about), and their resolutions.
# | Date posted | Status |
|
---|---|---|---|
84 | 07/22/02 | Closed | |
83 | 07/21/02 | Closed | |
82 | 07/14/02 | Closed | |
81 | 07/14/02 | To-do | The Win32 version and *nix versions do not agree in their treatments of the initial line of the sample etext. (But do treat the remainder of the sample etext identically.) |
80 | 07/13/02 | Closed 07/21/02 |
|
79 | 07/10/02 | Closed 07/14/02. |
|
78 | 06/16/02 | To-do. | In LaTeX, verse is rendered poorly (relative to the way it is rendered in HTML). If paragraphs are not indented (the default), there is an extra blank line in between every line of verse. If paragraphs are indented (--no-parskip), these blank lines don't appear, but if the verse is the first thing in the chapter the first verse line is not aligned with the others. |
77 | 06/16/02 | Closed. | |
76 | 06/15/02 | Closed 06/16/02. | |
75 | 01/24/02 | Needs investigation. | (Thanks to Curtis Weyant.) There is apparently a problem (e.g., lkhst10.txt) when the first lines of paragraphs are not indented, but the subsequent lines are; these are treated as verse by GutenMark. (Yikes! I never saw such a thing before.) |
74 | 01/24/02 | Under consideration | (Suggestion thanks to Curtis Weyant.) Provision might be made for a list of words which are never capitalized, except at the beginnings of sentences. |
73 | 01/24/02 | To-do. | (Suggestion thanks to Curtis Weyant.) Conversion of ALL-CAPS headings to upper/lower case (perhaps as a command-line option) would be useful. |
72 | 12/28/01 | To do. | For non-PG etexts, the same means of deducing title and author cannot be used as for PG etexts. Currently, non-PG title and author are left blank. |
71 | 12/27/01 | To do. | For OCR'd text that hasn't been proofread well, it is common to find that the OCR software has inserted a '~' character wherever it does not reconize a character. If this is the first character in a word, it will toggle italics mode on (see issue #64). Therefore, for the special case of ~italicizing~, GutenMark needs to look for a trailing ~ before toggling italics on. |
70 | 12/27/01 | Closed | |
69 | 12/20/01 | Probably needs AI. | In ytagn10.txt, there is a section titled
'273'Not surprisingly, this isn't recognized as a section heading. |
68 | 12/20/01 | Probably needs AI. | In ytagn10.txt, for the first time, we see a section that has subsections. GutenMark marks the first as a sub-heading, but cannot distinguish any of the rest from normal text. |
67 | 12/20/01 | We'll see ... | In ytagn10.txt, we find "o^" and "e^", presumably intended to be 'ô' and 'ê'. I'll have to find this same construction in other files before applying a fix in GutenMark for it. For reasons I don't quite grasp at this moment, this etext also encodes 'ç' as character #135, which doesn't correspond to anything in any character encoding I'm familiar with. |
66 | 12/18/01 | Probably impossible currently | (See also issue #32.) There are many characters which
don't appear in the HTML 4.0 character-entity set at all. Consider,
for example, the 6 different regional
encodings used by NIMA,
as compared to the HTML 4.0 entities.
While there is a substantial (or complete, in some cases) overlap for characters
'a'-'z', 'A'-'Z', and 192-255, there are also many characters simply missing.
This is probably not an issue for English-language (or at least, American)
readers, but still ...
Various issues make this very difficult. Probably, unicode is necessary. Even where browsers have fairly good unicode support, equal support is not available in the HTML-to-Postscript conversion (if used). Then, too, adding unicode support within GutenMark would be a pretty substantial undertaking ... |
65 | 12/18/01 | Closed | |
64 | 12/16/01 | Closed |
|
63 | 12/16/01 | Closed | |
62 | 12/16/01 | To do | A couple of cases (thdvn10.txt) in which the program is fooled into
treating verse as a blockquote:
|
61 | 12/16/01 | May be impossible | Blockquotes in which the volunteer has used abnormally short lines are indistinguishable from verse, and hence are not wrapped. Numerous examples appear in thdvn10.txt. |
60 | 12/16/01 | Closed | |
59 | 12/15/01 | To-do | Question: should mdashes surrounded by whitespace be normalized by removing the whitespace? |
58 | 12/15/01 | Closed | |
57 | 12/15/01 | Closed | |
56 | 12/13/01 | To-do | Normally, "I" is not italicized. However, if part of an all-caps phrase, like "I AM THE LIGHT", it should be. |
55 | 12/13/01 | Possible | Line drawings may now be recognizable (see issue #50), but they are merely converted to a fixed-width font, and not to an attractive drawing with lines that join up nicely. NOTE: Some browsers (like Mozilla) do support unicode line-drawing characters, but html2ps doesn't currently support them. |
54 | 12/11/01 | Closed | |
53 | 12/11/01 | Closed |
|
52 | 12/11/01 | Closed | |
51 | 12/10/01 | Closed | |
50 | 12/10/01 | Closed | |
49 | 12/10/01 | Closed | |
48 | 12/10/01 | Closed | |
47 | 12/09/01 | Possible | Consider alternate output formats: DocBook, XML, or RTX. (Thanks to Craig Morehouse.) |
46 | 12/09/01 | May be impossible | When "dialect" is used -- i.e., when the author has simply made up a lot of new words to express how something sounds -- there is a rather high probability that the made-up words match some words in a foreign language, and hence are rendered as italicized. A similar problem occurs if the author has simply made up names. |
45 | 12/08/01 | Possible | Consider the use of Cascading Style Sheets for the HTML. (Thanks to Terence Tan.) |
44 | 12/08/01 | Closed | |
43 | 12/08/01 | To-do | Investigate the feasibility of using the HTML tags <q> and </q> rather than opening/closing quotes. (Thanks to Terence Tan.) |
42 | 12/08/01 | Closed |
|
41 | 12/08/01 | Closed | |
40 | 12/08/01 | To-do | Need to check that texts in which single-quotes are used systematically in place of double-quotes (such as wuthr10.txt) are handled correctly. |
39 | 12/05/01 | Closed | |
38 | 12/05/01 | To-do | ALL-CAPS Roman numerals may or may not be handled correctly. |
37 | 12/04/01 | To-do | For people who actually want to view HTML output in their browser, most HTML files currently output will be too large. There needs to be a command-line option to break the file into smaller files, perhaps at chapter headings. |
36 | 12/03/01 | Closed | |
35 | 12/03/01 | To-do | Require a more-sensible installation procedure, with less manual steps. |
34 | 12/03/01 | To-do | There is an appearance of "--" not converted to emdash in bldhb10.html. It may involve a sequence such as "- -". |
33 | 12/01/01 | Closed | |
32 | 12/01/01 | Possible | Addition of diacriticals and ligatures (such as the oe ligature), which don't fit into the 8-bit subset of the HTML 4.0 character set, to the wordlists. |
31 | 12/01/01 | Closed | |
30 | 12/01/01 | To-do | Lists of proper names should be provided for more languages, particularly Latin. |
29 | 12/01/01 | Partially handled, for single-word placenames.
Full treatment to-do. |
Geographical references should not be italicized unless in ALL-CAPS, and should be capitalized properly in this case. Since many placenames are multi-word, this cannot be completely handled by the wordlist mechanism. |
28 | 12/01/01 | Ongoing | All existing wordlists, particularly Latin and German, require improvement. |
27 | 12/01/01 | Closed | |
26 | 12/01/01 | To-do | Automatic detection of text native language, rather than relying on command-line parameter. |
25 | 12/01/01 | To-do | Language-profile should be used to modify the type of quotation marks. |
24 | 11/26/01 | Fixed 06/15/02 | |
23 | 11/26/01 | Closed | |
22 | 11/26/01 | Closed | |
21 | 11/26/01 | Fixed 06/15/02 | |
20 | 11/26/01 | Fixed 06/15/02. |
|
19 | 11/26/01 | Fixed 06/16/02. | |
18 | Antiquity | Possible. | Bullets. I haven't seen many bullets in PG etexts, but I'm sure GutenMark won't handle them. |
17 | Antiquity | May be
impossible |
Illustrations. Well, PG etexts don't have illustrations. But still ... |
16 | Antiquity | May be
impossible within HTML. May need A.I. |
Spacing in verse or dramatic scripts. Verse and scripts (like
plays) are depicted in a variable-width font, and this may result in incorrect
alignment among successive lines. Consider the following example,
that might appear in a play, in which several characters respond simultaneously
to another character:
( Nonsense! | You're not serious! I'm leaving! { What! | Not a chance! ( That's crazy talk! The intention of the person creating the etext was clearly that a single large left-hand brace should precede the text at the right. GutenMark, however, will not only not add a large brace, but will jumble up the spacing so that it doesn't even look as good as it does here. |
15 | Antiquity | May need
A.I. |
Attributions. By this, I mean quotes which are set off from the surrounding text, and which are followed by the author's name (which is supposed to be at the far right of the quotation). Actually, GutenMark's treatment of this case seems to be not unreasonable, but it needs improvement to be professional. |
14 | Antiquity | May need
A.I. |
Detection and treatment of double-column verse. I'm not sure this appears in any actual Gutenberg text, but I know that it does appear in certain books that have been partially converted to PG, such as Burton's Arabian Nights. |
13 | Antiquity | Ongoing | Improvement of table-detection and treatment, as in FLYMC10.TXT. |
12 | Antiquity | To-do | Dealing with things like "right-" when appearing at the end of the line, as (for example) in the phrase "this happens with both the right- and left-hand versions." GutenMark would threat this as "this happens with both the right-and left-hand versions." |
11 | Antiquity | To-do | Use of systematic misuse of "-" where "--" was actually intended. |
10 | Antiquity | To-do | Removal of false hard-hyphens. For example, suppose one line of the etext ended with "soft-", and the next line began with "hyphen". Should this be treated as "soft-hyphen" or as "softhyphen"? |
9 | Antiquity | May need
A.I. |
Footnotes/endnotes. Innumerable footnote/endnote styles appear
in PG etexts. Here are some cases I've found:
|
8 | Antiquity | May need
A.I. |
Restoration of Greek transliterated to Latin, back into Greek. In some PG etexts, Greek text is simply discarded (and obviously cannot be recovered). In other cases it has been transliterated to Latin characters, but there are various schemes for doing so, and these are seldom specified. Furthermore, the transliterated text is often not marked in any way as being Greek. |
7 | Antiquity | May need
A.I. |
Restoration of missing currency symbols, particularly Pound (£) and Yen (¥). |
6 | Antiquity | To-do | Restoration of Spanish inverted exclamation points (¡) and question marks (¿). |
5 | Antiquity | To-do | The ability to recognize and italicize book titles should be added, along with a database of book titles in various languages. |
4 | Antiquity | To-do | Determination of Title/Author should be improved by using PG header data rather than just the first line of the file. |
3 | Antiquity | Ongoing | Recognition of verse vs. normal paragraph text needs improvement. |
2 | Antiquity | Ongoing | Identification of "prefatory" section needs improvement. |
1 | Antiquity | Ongoing | Identification of section headings needs improvement. |