Just for historical accuracy - the Font property is my doing - it came in with the Persian Bibles about 7 years ago, via Xiphos or BibleDesktop
Mea culpa. Peter On 12/02/12 16:19, scribe...@gmail.com wrote: > Thanks for delineating the discussion, DM. > > I would certainly be in favor of discussing the possible enhancement > to our filters (or import tools) for providing language span tags > around segments of language text not included in the default module > language unicode plane, per the BPBible team's suggestion and > possibly their code :) > > And I know you guys enjoy proclaiming me wrong (Peter), but I can't > remember recently defending the font= property in the .conf files. > This was useful 20 years ago when it was added, before our > non-English Bibles became unicode encoded. :) But certainly isn't > ideal now. It's still a fine convention if a user or module author > wishes to specify a preferred default module font, so I'm not > suggesting we remove it, but it certainly doesn't handle per-language > font suggestions in its current incarnation. > > Troy > > > > DM Smith <dmsm...@crosswire.org> wrote: > >> 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 importance of what the desires of >> the publisher and whether that can be known. Regarding footnote >> markers, JSword's frontends use the value of the n attribute when >> present because the footnotes are rendered on the screen as margin >> notes. If the n attribute is not present we generate a unique value >> for each one on the page. It fits well with desktop applications, >> but not perhaps when the notes are not present in the user's view >> such as on a phone. >> >> 2) Separation of structure and presentation. I think we have agreed >> in the past that these should continue be separate. What we have >> not come to agreement on is how to allow for a "publisher" to >> provide for rich presentation. We have noted that using class >> attributes in the render filters would enable such a future, but no >> one has stepped up to doing it. >> >> But the landscape of the device (size, dimension and resolution of >> the viewport/screen/window/frame) is a crucial part of any >> presentation and it precludes a one size fits all presentation >> style. >> >> I really don't like when a publisher works toward a single frontend >> as it may use features that only work for that frontend. >> >> 3) Needs/weaknesses of the frontends. E.g. font. I'm wondering >> whether it makes sense for CrossWire to host the fonts that are >> specified in the modules it hosts and SWORD be modified to download >> such a font on demand. That is it'd be a feature of a repository. >> >> Regarding lang="XX" it (the two letter code) works well for >> languages that only have one script, such as English, Greek and >> Hebrew. But not for those that have multiple scripts. It needs to >> be extended to include script. I think that the multi-language >> modules should copiously specify the language/script of the >> elements. Osis2mod should be modified to push these down into the >> verse entries if needed. Likewise for gen books and dictionary >> module makers. >> >> In Him, DM >> >> On Feb 12, 2012, at 7:34 AM, Jonathan Morgan wrote: >> >>> Hi, >>> >>> On Sun, Feb 12, 2012 at 10:16 PM, Peter von Kaehne >>> <ref...@gmx.net> >> 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 this >>> really >> got >>> my notice. >>> >>> I think the current Font item in the configuration file is a bit >>> of a cludge - it does not work when a font is not actually >>> present, it can not deal with font families, alternatives etc and >>> it certainly can >> not >>> provide a selection for multiscripture texts. >>> >>> FWIW, the way BPBible does it is to scan through a text, identify >>> all >> Hebrew/Greek text, and wrap them in additional spans like <span >> lang="he">. It will then use the font specified by the user for >> that particular language. Due to the implementation, this would >> probably end up with a more specific rule than anything in the CSS, >> which may be a drawback (especially since the default will probably >> be the default font for the entire application). However, it does >> mean that the user is (at least in theory) in control of which font >> is used for which language, rather than the module, so if module >> creator explicitly picks font X because it has good Hebrew support >> but user prefers font Y for Hebrew they get font Y. And it does >> mean even in a principally English book Hebrew/Greek text in it can >> be displayed in a different font without any work from the module >> creator. >>> >>> Jon >>> >>> So, Greg is right here. And you Troy are wrong. Said with the >>> same >> love >>> present in your last email :-) >>> >>> Whether the solution is style sheets or something else, I do not >> care, >>> but to my mind, given that we moved all to immensely capable >> rendering >>> engines and use only a single digit percentage of their ability, >>> I >> think >>> a move to support per module CSS would not be exactly a big >>> thing. >>> >>> Certainly not if we restrict its use to something which can be >> expected >>> to have universal support across all our frontends (leaving >>> BibleCS >> and >>> its RTF rendering out of the equation. >>> >>> I personally would find it hard to have pink headlines and >>> turquoise coloured backgrounds because a girly module maker >>> thought this would >> be >>> nice, but structural stuff - fonts particularly - need to improve >>> and could easily be improved. >>> >>> Peter >>> >>> >>> _______________________________________________ sword-devel >>> mailing list: sword-devel@crosswire.org >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >>> >>> _______________________________________________ sword-devel >>> mailing list: sword-devel@crosswire.org >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >> >> _______________________________________________ sword-devel mailing >> list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel Instructions >> to unsubscribe/change your settings at above page > _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
