I just committed an updated patch to accomplish this, with Troy's OK.
He didn't like abusing RenderText() (and he was right), so it is
implemented as a trivial setRenderNoteNumbers(bool) in each of the 7
*htmlhref and *xhtml filters.
___
sword-devel mail
Karl,
Just a brief note:
On 02/12/2012 10:01 PM, Karl Kleinpaste wrote:
> You don't think publishers care whether what you put on the screen bears
> an excruciatingly close resemblance to what they encoded in the content
> with which you have been entrusted?
>
> Just...wow.
I don't believe that
"Troy A. Griffitts" writes:
> Again, I am not arguing against displaying publisher provided labels.
> I am arguing against forcing all frontends to display publisher
> provided labels.
If I were an author/publisher, I would walk away from Sword on that
basis alone. I'm not kidding one iota.
I (
Greg Hellings writes:
> You are using Lockman and the NASB as your example because of its
> prevalence all over the web.
[a] There is indeed an irritating difference between print publication
and electronic publication in footnote standards. I argued a bit some
years ago with bible.org people ov
On 02/11/2012 09:27 AM, Greg Hellings wrote:
What I have tried to propose before with CSS, and what Karl has
proposed here with footnote and cross-reference notes is that the
application ought to provide good defaults (generated cross-reference
and footnote markers when they are lacking) but to
This has evolved a bit from the original question: should the engine provide
direct support for n="X" footnote markers.
The answer to that was yes and it was implemented as an optional change.
We've digressed into several distinct discussions. Here are my comments on them:
1) What is the importan
Hi,
On Sun, Feb 12, 2012 at 10:16 PM, Peter von Kaehne wrote:
> On 12/02/12 04:27, Greg Hellings wrote:
> > Still more of it was very
> > important for display - selection of different fonts for Greek vs
> > Hebrew vs Aramaic displays.
> I do not follow the general discussion very much - but thi
On 12/02/12 04:27, Greg Hellings wrote:
> Still more of it was very
> important for display - selection of different fonts for Greek vs
> Hebrew vs Aramaic displays.
I do not follow the general discussion very much - but this really got
my notice.
I think the current Font item in the configuration
OK, we seem to be talking past each other. You are using Lockman and
the NASB as your example because of its prevalence all over the web.
I'm specifically not talking about Bibles. As I stated in my previous
email, most of those have footnotes which start over on every page,
even in print. If you g
Well, I listed my downsides in my last message. I don't like looking
for the corresponding letter reference on the page, as showing the
letter reference implies that you need to find the corresponding letter.
A downside of citing is our labels is that we only have about 2 modules
that contain
On 02/11/2012 09:27 AM, Greg Hellings wrote:
What I have tried to propose before with CSS, and what Karl has
proposed here with footnote and cross-reference notes is that the
application ought to provide good defaults (generated cross-reference
and footnote markers when they are lacking) but to
Er, sorry about that. I was writing 2 emails at the same time and
tacked the end of one to the middle of this one and sent this one off... :)
continuing
On 02/11/2012 06:25 PM, Troy A. Griffitts wrote:
Dear Greg,
I respect your opinion, but... you're wrong ;)
None of the arguments give
Dear Greg,
I respect your opinion, but... you're wrong ;)
None of the arguments given are persuasive to me.
1) footnote are for external reference.
This cannot be true if the software application always starts with
generating their own footnotes at the start of the text.
For example. If I
I just wanted to reply to the following by Troy and also to his
comments in #xiphos regarding this topic
>BibleCS, per my preference, only shows hover-over symbols for the note or
>cross reference, and does not
>include the 'n' label. BibleCS uses different filters though, so not affected.
>
>SWO
I figured that the colour was just a little extra indication (they also
vary on the type of footnote e.g. insight, translation, etc.)
I think you'll find in most versions (e.g. NASB, ESV) that the type of note
is clearly distinguishable by the letter/number assigned to it. i.e.
numbers for footnot
Hi Karl/Ben,
On Thu, Feb 9, 2012 at 11:32 AM, Karl Kleinpaste wrote:
> "scribe...@gmail.com" 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 ver
I'm not sure I follow the code (I've been a long while away from C/C++, so I
could be misreading it altogether), but it looks like it expects the value of
the n attribute to be a single character. If so, I think there might be
problems.
IIRC the ESV has values for n like a, b, c, ... z, aa, a
Attached is an updated patch to do this as suggested by Greg. It makes
RenderText() take another default-value argument. No change to old
behavior, unless you explicitly provide that (4th) parameter as "true".
The patch sets a field in SWModule, which is then pulled into the
filters' user data s
"scribe...@gmail.com" 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
In all seriousness though, 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?
Greg, your wife and new baby and you are in our prayers!
"scribe...@gmail.com" wrote:
>Abs
On Tue, Feb 7, 2012 at 10:31 PM, scribe...@gmail.com
wrote:
> Absolutely not. Go have a baby!
I'm sitting in the hospital. There's not much for me to do at the
moment. She's scheduled for induction in the morning, which means
they're just making sure she's hydrated and the baby has a good heart
r
Absolutely not. Go have a baby!
Greg Hellings wrote:
>On Tue, Feb 7, 2012 at 10:24 PM, scribe...@gmail.com
> wrote:
>> BibleCS, per my preference, only shows hover-over symbols for the
>note or cross reference, and does not include the 'n' label. BibleCS
>uses different filters though, so not af
On Tue, Feb 7, 2012 at 10:24 PM, scribe...@gmail.com
wrote:
> BibleCS, per my preference, only shows hover-over symbols for the note or
> cross reference, and does not include the 'n' label. BibleCS uses different
> filters though, so not affected.
>
> SWORDWeb will be affected.
>
> My thought o
BibleCS, per my preference, only shows hover-over symbols for the note or cross
reference, and does not include the 'n' label. BibleCS uses different filters
though, so not affected.
SWORDWeb will be affected.
My thought on this is similar to strongs. Don't show the numbers. They are left
ove
Bible Time does its own thing and wouldn't be bothered by this change. It
dispenses with any semblance of delineation. Both notes and cross
references are marked with "(*)" everywhere they appear.
--Greg
On Feb 7, 2012 9:38 PM, "Karl Kleinpaste" wrote:
> To date, we have DM in support of n=X con
BPBible uses its own filters for notes to put the note number/letter in, so
it shouldn't affect BPBible at all.
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
To date, we have DM in support of n=X content in *n/*x, as well as Brian
noting that consistency should be supported in that note numbers provide
the common language of note reference.
No one has suggested that such an update is a bad idea, though Troy
wondered aloud the other night in #xiphos abo
I'd suggest that it should be consistent. When one references a
footnote in a printed work, it is common to reference the page and
bookmark number. If (or more accurately because) we don't have a
consistent marker for each footnote between front-ends, we lose the
common "language" to referenc
When I got home late last evening, I found that Troy and Greg had had a
conversation about this in #xiphos. Troy theorized and Greg confirmed
that Xiphos must be calling RenderText() too often; I hadn't noticed
this -- it happens in a "bridge" routine in Xiphos' backend by which to
call the engine
I've always thought that the value of the n attribute should be used if it were
there.
Cent from my fone so theer mite be tipos. ;)
On Feb 4, 2012, at 1:34 PM, Karl Kleinpaste wrote:
> Quite a while ago, Xiphos gained the capability to post-process the
> *n/*x that come out of the engine so a
Quite a while ago, Xiphos gained the capability to post-process the
*n/*x that come out of the engine so as to add the n=X identifiers that
emanate out of OSIS and ThML markup. This is a fine and welcome idea,
but we have run into a problem.
Some modules have single-section content that is really
31 matches
Mail list logo
