paul flo williams said:
> Small caps are frequently used to indicate
> when a personal name at the end of a letter
> is actually a signature. That is the case here.
in the books i've reviewed from jim thus far,
some of the text that is tagged as small-caps
is indeed the name at the end of a letter. but
sometimes it is frontmatter instead, or some
other stuff. plus, i'm not sure that everybody
understands the convention you've described,
or even whether it _is_ "a convention" or not...
it's also the case that we can question whether
it's a _meaningful_ distinction we should make.
does it really matter if it's a signature, instead
of... a printed or typeset instance of the name?
is it _vital_or_meaningful_ for us to know that?
if it is, and we decide that small-caps is the best
way to make that distinction, we certainly could.
but i can't say i'm convinced, in the general case,
that that information was communicated to us,
intentionally or otherwise, or that it is important.
> In the presentation of genealogical information,
> they are also used to distinguish individuals
> whose line will be explored further
> from those who are not.
this seems like it could be a _useful_ distinction,
but i don't really have the experience to know, so
i would defer to the people who cared about this...
it would seem like "further exploration" might be
self-explanatory, as would the absence of it, but
again, that question's for someone else to answer.
for our tool, if we decide that we need small-caps,
then we just need to decide on a way to _tag_ that.
and -- just so i am completely clear about this --
there will be times where the small-caps in a book
_do_indeed_ communicate something important,
something structural and/or semantic, and there's
absolutely no question that we should capture that.
(although it's not required that _we_ show that info
using small-caps. we could use some other means.)
> Small caps are a reasonable choice, and if they
> are in the original, why not mark them up as such?
from the standpoint of the tool, it matters not a whit.
from the standpoint of _digitization_, however, we
decide for ourselves what we want to keep, and not.
sometimes small-caps are nothing but "decoration",
like the first few words at the beginning of a chapter,
and my vote would be to discard decorative frivolity.
but if you have a community of digitizing volunteers,
then _they_ should be making decisions like that one,
as a whole, so the library that they create is coherent.
if they want to keep the decorative elements, so be it.
(a problem with p.g./d.p. is that every post-processor
makes such decisions, so the library is composed of
a myriad of "snowflake editions", with no consistency.)
> If we didn't, what would be "a substantial way
> to indicate their actuality"?
how you decide to tag something isn't all that difficult.
and how you decide to represent it isn't too hard either.
but you wouldn't know this from the d.p. forum-boards.
ever since the decision was made to mark up small-caps,
specifics have been one of the most contentious topics...
so no, i'm not gonna jump in that cess-pool myself. :+)
i would just want to point out that we've already touched
on 4 different "semantic" meanings that small-caps have,
and -- if you really want to do the job correctly -- you'd
have to differentiate those structures from each other...
in the long run, i doubt the effort would be worth it, but
-- just to repeat it again -- i'd let the community decide.
> I have a book of poetry in which some of the lines
> are so long that they wrap, and the publisher
> has taken care to indent the wrapped part.
if small-caps are a cess-pool, then poetry is a feed-lot in
california's central valley, drowning in a sea of cow-poop
and rank with a suffocating stench of ammonia in the air.
nobody knows what to do with poetry -- nobody at all --
probably because it's an insolvable problem at its root,
since you simply cannot fit long lines on a small screen;
something or other about violating the laws of physics...
so if you think you have a solution, you let me know, ok?
> Marking up individual lines with divs
> will allow a more flexible presentation
prove it.
> you'll be able to cope with indentation
> and wrapping in one go, whatever the
> readers' chosen screen width and font size.
no. big font + small screen = big problems, and there's
absolutely no way that you can get around that equation.
> Jim has already said that
> he has tried a variety of tools over time
jim has said a lot of things, and often contradicts himself,
so i've stopped trying to figure out what he really means.
indeed, i have quit reading his posts entirely, thank you...
> he has tried a variety of tools over time and
> that he wasn't pleased with all the results.
well, most of his stuff works well enough, for its purpose,
as far as i can see... his .html is often remarkably _ugly_
(which is what we'd expect if he used "a variety of tools")
and that's probably what he's talking about, but it works,
and that's really the most important thing, in my opinion.
at least it works when used as intended, not for "remixing".
> However, if you weren't so keen on pillorying his efforts
except i'm _not_ "pillorying his efforts". not in the slightest.
as i have just said, jim's books _work_ as he intended them.
they work as well as all of the other books in the p.g library.
i have showed that the books he's done aren't very complex,
but that's true of most of the books in the entire p.g. library.
(which is -- at the base -- the point of the point i'm making.)
i have also showed that his .html is often far too unwieldy,
though i haven't stressed this point strongly, at least not yet,
because this will become apparent when i show the _simple_
and _quite_uncomplicated_ .html which my tool will generate.
that's the game-plan, the travel-map for this little excursion...
to show that the very simple books can have very simple .html,
and that the more-complex books can still have simple .html...
> you'd see that some of the markup you decry
> as presentational or "cruft" is just what we need
> to preserve the original work with fidelity and flexibility.
when i decry something as _cruft_, that's because it is _ugly_,
and usually _unnecessary_ as well. for instance, some of the
books we have examined from jim have the occasional "div".
there's no _reason_ we need those div's; they're unnecessary.
they don't provide support for "structural" or "semantic" needs.
so they're not doing anything useful; they just gunk up the text.
i'm sure they're some leftover garbage from some tool jim used.
they're not really _hurting_ anything, _except_ for our ability to
_comprehend_ the .html, and to subject it to future massaging.
so we will learn the lesson, and make sure that the tool we build
will not place unnecessary cruft like this in the output it creates.
but having said all that, let me also make it clear that the mission
_as_i_define_it_ is most certainly _not_ to "preserve" any "fidelity".
my aim is to bring a paper-book into the digitized 21st century;
i'm electrifying an acoustic guitar -- i'm turning it into a gibson.
so i don't care if the paper-book didn't have a table-of-contents,
because the e-books that i create _do_ have a table-of-contents...
and their table-of-contents is _called_ a "table of contents" --
even if the paper-book labeled that section as merely "contents".
yeah, i know some people say "table of contents" is redundant,
but i often use a belt _and_ suspenders in my e-books, so there.
and no, i'm not gonna put _presentational_ decorative frivolities
in my e-books, like small-capping the first words of a chapter...
if something is small-capped, it'll be because there's a _reason._
and that's not because i eschew such presentational doodads...
i'm more than willing to code an option such that when a person
reads one of my e-books, they can small-cap those initial words,
by having the viewer-program render those words in that manner.
but i will not _mark_ that in the _file_ as if it _meant_ something.
to mix meaningless with meaningful robs the value of meaning.
to my mind, that's just good common sense, no more, no less...
still, i repeat, if your community decides it will mark it in the file,
then hey, more power to you, to each his own, viva la difference...
-bowerbird
