On 2012-10-08 18:25, Bowerbird@aol.com wrote:
jeroen said:
Please inspect one of my most recent submissions
now on to my reactions...
although i can't be positive, because of the german, it seems to me that this markup is quite acceptable. (aside from troubles specific machines might have.)
I have prepared plenty of English books as well, for example this one: http://www.gutenberg.org/ebooks/40807. A book that also suffers from lots of tables...
i'm not sure if the tables will work with a small width, so that'd be something to check, and fix if necessary.
A problem that often goes beyond a mere formatting decision. To make tables work on a small size, you'll probably have to re-arrange the information in them in some smart way. For some tables, transposing might work, others may need to split in multiple tables that follow each other.
pagenumbers always present a problem, because they get mixed in to the text. the best solution for that is to make them easily visible to a reg-ex, for removal...
in this particular book, the square-brackets work fine, because you don't have any other occurrences of them, but that won't always be the case, so i'd recommend that you add an additional component, such as [#69]. or -- if a number-sign seems too intrusive to you -- you could use nbsp around the bracketed pagenumber.
In HTML, they all have a class (<span class="pagenum">), so they are easy to filter out.
your "inhalt" links jump to the actual place in the t.o.c. that match the jump-point, which is something i have often thought about doing, but usually decided against, relying instead on a jump to the top of the t.o.c. page. in working with your file, i think my instinct was right. when i jump back to a table of contents, i don't wanna see the contents _from_that_point_down_, i want it all. or at least i want the contents _around_ the jump-point.
This is a new innovation, and I still have to decide how I like it. Jumping several lines above the actual link is a good idea, but hard to implement.
(if browsers didn't put the target-point at the _very_top_ of the window, but instead showed some context-lines, which is something that i've always argued they should, i might prefer your method. but as it is, i prefer mine.)
the most solid recommendation i would have, though, is for you to re-think your policy on creating link id's... right now, they are some weirdish alphanumeric string, which might have some rhyme or reason to it, i didn't bother to try to figure it out, but it's still far too cryptic.
Link Ids are created by the transformation software. Where the source does have a predefined id, they are reused (e.g. EthnographiePhilippinen.html#ch2.19), but otherwise they default to whatever the XSLT processor cooks up.
i generally use the text of the jump-point itself, so that people who are looking at the text can _guess_ the link and almost always be correct, with a very high certainty.
it's often the case that we think of the id element as an internal reference that only the computer needs to know, but it actually serves to create a deep-link into the text, so it has to be human-readable and even "make sense".
I agree, and they should be stable, so users can rely on them not changing at a whim of the web-publisher.
anyway, that's my feedback, based on a quick once-over.
Thanks for that, Jeroen.