Martin Gruner wrote:
DM,
I guess that it would be good to add another value to the Direction= field
(TLtoBR?).
I think that "tb" should be a separate setting since it can either be
rtol or ltor, depending on the language.
This way if a frontend cannot honor "tb", it can still honor rtol.
It may also be necessary to indicate whether the characters are also
supposed to be rotated, "tbr".
Since is obligatory it cannot be a user preference. Only the drawing of the
text itself has to be handled by the frontends.
There might be ways to "emulate" TLtoBR by using tables (one char per cell).
This should be fairly easy, though it might look ugly. What do you think?
It depends on the language and the widget that is used to do the
rendering. There is a nice discussion about this at:
http://www.macdevcenter.com/pub/a/mac/2002/03/22/vertical_text.html
(In this solution, images are created on the fly.)
This provides some insights into the issues involved.
One thing that I never thought about was the impact of vertical text on
the layout of the widgets. In JSword, we set the orientation to either
left to right or right to left. With our extensive use of tabs, this
makes sense. But in a right to left, top to bottom world, I guess the
tabs should be on the right.
The problem with one char per cell is that the text becomes fixed width
rather than proportional width. (Not to mention the computation
necessary to compute which character goes in which cell with the added
complication of figuring out how to word wrap assuming that word
boundaries can be determined.)
When I read I don't really care that one line of text lines up with the
one above it. (except when reading code!) I doubt that it will matter
that characters in one vertical column line up with the ones drawn to
the right of it. (Though this is just a guess.)
However, my guess is that fixed width vertical text is better than no
vertical text.
Also, some languages join adjacent characters into a single glyph. I
presume that ICU would be of some value here. This would complicate the
algorithm to compute the content of a cell.
Another problem is that rendering tables can be very slow and memory
intensive.
My perspective is that of a Java user interface. Currently we are using
a JTextArea to render html. JTextArea's handling of html is that it is
horribly slow in showing a table, taking lots of RAM and its ability to
render html at all is really limited. For these reasons, we are strongly
considering a move to using a native browser on the user's platform (IE
on Windows, Safari? on Mac and FireFox elsewhere).
As I weigh this against what else we want to do in BibleDesktop
(JSword's GUI), I find that there are other things that I want to work
on more. One of the nice things about open source is that those people
that really care can join in and work on providing a solution.
Once the major browsers implement vertical text, it probably will be
easy to put it into BibleDesktop.
mg
Am Donnerstag, 9. Februar 2006 18:03 schrieben Sie:
Is there a need to add to the conf a field that specifies top to bottom
like we have for right to left? (Or to extend that field?)
Or is there a way to determine it from the language field? Or should it
be a user preference and handled entirely by the front-end?
Martin Gruner wrote:
This will have to be handled in the frontends, and thus for every
platform separately.
Some people extended QT/KDE to be able to draw vertically:
http://dot.kde.org/1130546299/. I don't know if this has already been
integrated into QT4.
mg
Am Donnerstag, 9. Februar 2006 16:00 schrieb DM Smith:
I took a look at IE's write-mode: tb-rl and it rotates the characters as
well as the text. Probably not what is wanted.
CSS3 specifies this ability but IE does not handle it (don't know about
IE7) and I didn't check FireFox 1.5 or Opera.
When the major browsers support CSS3 then perhaps
www.crosswire.org/study can be changed to use it.
Joachim Ansorg wrote:
Hi.
A friend of mine is just finishing the translation of the NT into
traditional Mongolian. He works together with the UBS and the local
curch here in cina. Now my question: how can I get the document ready
for the sword project? Is there already a Chinese program version? if
not what do I have to do to translate the version.
At http://www.crosswire.org/sword/develop/swordmodule/ is some
information how to prepare a module.
I think a chinese translation of the windows software is available.
For Linux it's not difficult to prepare a new translation if there are
volunteers to do the actual translation.
One more technical question: Mongolian is written vertical with the
first column left towards right. I am a developer myself. is there a
way to enable the sword sw to write vertical?
Hm, I don't think this is possible atm.
Afaik Internet Explorer has some hacks to display mongolian, but this
is not available in the windows software.
SIL/Wycliffe has some work going to enable applications to render more
languages, the project is called Graphite. But I'm not sure about the
current status.
Joachim
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: [email protected]
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
