[sword-devel] proposed patch: adding n=X marker content to footnotes and xrefs

[Jonathan Morgan]

Hi Karl/Ben,

On Thu, Feb 9, 2012 at 11:32 AM, Karl Kleinpaste <karl at kleinpaste.org>wrote:

> "scribe777 at gmail.com" <scribe at crosswire.org> writes:
> > My thought on this is similar to strongs. Don't show the numbers. They
> > are left overs from the era of print-only.
>
> I disagree about that.  Footnote/xref markers are obligatory in a very
> large variety of publications, regardless of print or electronic form,
> exactly because of the point Brian made: Reference markers are the
> common language by which to identify their content.  If someone writes
> commentary on a document to argue against the observation made in
> footnote #37, then everyone in the world reading the same document knows
> exactly what he's talking about.  We don't expect people to count
> anonymous markers until they find #37, nor do we expect the commentary
> author to identify "the footnote preceding 'word' in verse X."
>
> In any event, not displaying those markers represents a loss to the user
> of the author's or publisher's information.
>
> > The exception use case is possibly our NET module which has a
> > commentary accompaniment module which might refer to footnotes by
> > label.  If I remember correctly.
>
> NETnotes contains numbered footnote content, and NETtextfree is the
> version of NET whose footnotes refer only to the numbered footnotes.
> (And my own spins of NET are similar though hugely enhanced.)
>
> Greg Hellings <greg.hellings at gmail.com> writes:
> > SWModule::RenderText(bool includeNumbers=false)
> > Would that do the trick?
>
> "scribe777 at gmail.com" <scribe at crosswire.org> writes:
> > Greg's idea for a flag is a good alternative to the span. I believe we
> > have some other class statics in the filters for configuration. We
> > could add the flag there. Thoughts?
>
> This would suit me fine.
>
> Ben Morgan <benpmorgan at gmail.com> writes:
> > Personally, I've never liked the *x/*n style and I think that in
> > particular *xA/*xB looks very ugly.
> > BPBible just outputs the letter/number, but colour-codes the
> > note/cross-reference to distinguish between the two. This in my
> > opinion gives a much cleaner look.
>
> The display of *n/*x is from considerably farther back in time than when
> I got involved with Sword, 6 years ago.  When I added n=X post-process,
> I simply appended X to what was already there.  I'm open to other ideas,
> neutral about the exact form that it takes.
>
> With one exception, that is: Color-coding becomes a progressively harder
> problem because we already offer a lot of color configuration and usage
> in Xiphos.  We have basic fg/bg (b/w), high-contrast highlight fg/bg
> (navy blue/yellow), verse# (light blue), link (default grey; I use
> orange), and current verse colors (green).  Then there is Red Words, and
> finally Xiphos complicates it all by providing color pair inversion as
> an option for normal text (to get "night mode" easily) and highlight.
> By this time, finding another sufficiently distinct color from all the
> other stuff happening becomes difficult.  The search for colors that
> look good enough in both black-on-white and white-on-black is hard, and
> we've recently tweaked some of our default colors expressly to deal
> better with visibility in both cases.
>

Standard accessibility guidelines say that making important differences
solely on the basis of colour is not a good idea.  However, if the colour
differences provide a little extra that's fine.

The funny thing with BPBible is that I'm sure the colour differences for
notes and cross-references worked for Ben, because he wrote it.  However, I
could not figure out why different numbers were different colours, and
eventually read the source to figure out why.  My point (I guess) is that
the important thing is that the differences have a meaning to your users,
not just you (though I guess it doesn't make *that* much difference in the
long run if the user wants to read the note whether it is a note or a
cross-reference).

Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.crosswire.org/pipermail/sword-devel/attachments/20120209/1c12a525/attachment-0001.html>