Not all languages have fonts that include italics as a text style.
Italics are generally unavailable except for the scripts that use Latin,
Greek and Cyrillic alphabets.
[probably a gross over-simplification, but you get the gist of what I'm
saying]
So what should front-end applications use for
I guess a separate page would have been preferable, Chris.
e.g. one headed Ideas for further projects.
with subsections for
== Ideas for front-end applications ==
=== Platforms with no front-end application ===
=== Application frameworks with no front-end application ===
PS. As for navigatio
On 19/04/11 09:02, David Haslam wrote:
> So what should front-end applications use for presentational rendering in
> such modules when the Bible translation features added words?
> i.e. In USFM as marked using \add_...\add*
And in OSIS the markup is in a similar way semantic, not presentational.
On 18/04/11 19:51, David Haslam wrote:
> Probably something that could be easily implemented by making a bespoke
> TextPipe filter.
usfm2osis.pl should be relatively easy to adapt to this. I remember
thinking about it once when I saw a website aiming to create
multilingual Strong dictionaries/
Pe
Hi, Andy.
You haven't answered on this list. And i just would like to know, was
content i have sent to you useful for you? Whether you have understood
how that data was organized?
God bless.
> Hi all,
>
> I am working on preparing text for 2 Central Asian languages and as
> we test differe
The question was prompted by encountering a translation in which the
translators are currently using MS Word (i.e. rather than Bibledit or
Paratext), and for which they were marking added words in a shade of grey.
As it happens, they could have [also] used italics in MS Word, and had even
made som
On Tue, Apr 19, 2011 at 3:24 AM, Peter von Kaehne wrote:
> Alternatively, the more semantic HTML markup of might be useful?
There has been a move away from pushing and in the HTML
world, since it has been recognized that italics do not always
semantically mean "emphasis" and bold does not alwa
On 04/19/2011 09:27 AM, Greg Hellings wrote:
On Tue, Apr 19, 2011 at 3:24 AM, Peter von Kaehne wrote:
Alternatively, the more semantic HTML markup of might be useful?
There has been a move away from pushing and in the HTML
world, since it has been recognized that italics do not always
seman
On 04/19/2011 04:24 AM, Peter von Kaehne wrote:
On 19/04/11 09:02, David Haslam wrote:
So what should front-end applications use for presentational rendering in
such modules when the Bible translation features added words?
i.e. In USFM as marked using \add_...\add*
And in OSIS the markup is in
Another problematic markup for other languages is
...
The SWORD engine tries to apply small caps to the content by simulation.
The first letter is converted to uppercase if it isn't already. Then the
remainder of the word is converted to upper case and wrapped in code
that reduces the font size
> >> Alternatively, the more semantic HTML markup of might be useful?
> > There has been a move away from pushing and in the HTML
> > world, since it has been recognized that italics do not always
> > semantically mean "emphasis" and bold does not always semantically
> > mean "strong". This si
On Tue, Apr 19, 2011 at 9:35 AM, DM Smith wrote:
> In principle, I like the idea of CSS, but I think there are difficulties
> with CSS. It presumes the elements and structure of what is being styled and
> that the display can handle it.
Are these problems greater than our current solution of "Sor
Leaving aside the cencerns of implementation the identified issues where the we
currently systematically fail non Latin scripts (and many non english languages
with latin script) are, by applying English standards
1) references
2) divineName
3) emphasis/highlighting
4) quotations (partially add
On Tue, Apr 19, 2011 at 10:24 AM, Peter von Kaehne wrote:
> The interpretation happens very late in our chain - at rendering filter
> level. And I would think it is probably a wrong
> decision. It would be trivial to change that to which in turn might be
> rendered more likely in an appropriat
Again, to be rude and top-post, not having a specific line in the
message to which I wish to comment...
I don't believe anyone is against HTML rendering frontends supplying
stylesheets to their output.
I believe Bibletime does this for their user selectable themes.
I have often lamented the fact
On Tue, Apr 19, 2011 at 11:13 AM, Troy A. Griffitts
wrote:
> Again, to be rude and top-post, not having a specific line in the
> message to which I wish to comment...
>
> I don't believe anyone is against HTML rendering frontends supplying
> stylesheets to their output.
>
> I believe Bibletime doe
On 04/19/2011 12:00 PM, Greg Hellings wrote:
KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely. I think we're not dealing
with a language-level problem here but a translation-level problem.
Some translators recognize that they are required
On 04/19/2011 01:10 PM, DM Smith wrote:
On 04/19/2011 12:00 PM, Greg Hellings wrote:
KJVs used italics. Some English translations use [word]. Some use
⌊word⌋. Some ignore the issue completely. I think we're not dealing
with a language-level problem here but a translation-level problem.
Some tra
Hi Konstantin,
Sorry for now answering earlier - your file has been incredibly helpful in
trying to understand this and to chase down where this mapping should come
in!
However I am still trying to pick my way through this!
It seems that there are not only different versification formats (KJV and
Guys, I wonder if someone could give me a piece of advice on a problem
which bugs me. Enormously.
We do have an Arabic vowel filter which is essentially the same as the
Hebrew points filter. In fact they are so similar that Chris at one
stage wondered whether to amalgamate them and throw into it a
On 20/04/2011, at 3:15 AM, DM Smith wrote:
> Troy's suggestion of changing this from word to class="added">word is a good one.
>
> This removes the problem from the engine.
>
> With a well-defined output with class attributes, then CSS can solve the
> problem on a per module basis.
Sorry for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19/04/2011 08:15, David Haslam wrote:
> I guess a separate page would have been preferable, Chris.
To me, it doesn't matter if those non-projects are on the same page, or
a different page. What I find useful is that it is an acknowledgement of
the
22 matches
Mail list logo
