Thank you, Troy! With these explanations I understand the big picture of
markup transformation and filters a bit better!
For now, I'll go forward with the FMT_OSIS option for the
MarkupFilterMgr in node-sword-interface. I understand from your
explanations that this produces similar results as
Hi Tobias,
Great that the encoding issue is solved. If you really want to handle OSIS
yourself (which is a lot of work) I would recommend requesting OSIS markup.
Remember, we support various markup formats. Not everything is OSIS. If you ask
for OSIS then you should get generally the same marku
Hi Troy,
Thanks for your help! I have just tried using this parameter for the
construction of SWMgr and it looks good.
I had another look at the example for the German Rieger commentary where
I observed the encoding issues before and they are gone now!
Well, I guess I could have asked one or
Hi Tobias,
Yes, our documentation certainly needs much improvement. I am surprised how far
you've gone with so few questions. You have a great talent for figuring things
out. I wouldn't worry about the guts of the details in the encoding filters.
All you should need to do is specify your desire
Thanks Troy!
I'll have a look at the EncodingFilters.
I think this is something not fully clear from the SWORD
documentation/examples.
Maybe these transformation points you had mentioned in the thread below
should be described somewhere in the developer wiki?
Best regards,
Tobias
On 4/3/2
Dear Tobias,
Please be sure to note my comment to you below in this thread. It is likely the
cause of your rendering issues, while other apps have no problems.
In brief, it says that I haven't seen anywhere that you tell SWORD what markup
and encoding you want from the engine. If this is the ca
Hi Dominique,
I just forwarded to you what I had sent to Cyrille.
NB. It was sent from my btinternet address.
As for a TextSource key, the original text is barely altered.
It's essentially still what was received from Tero Favorin (tero at favorin dot
com) that was used to build Version 1.1 (see
NB. I did not change this key from the original
SourceType=GBF
Strictly speaking, even though IMP has been used for my rebuild ten years ago,
if there were any significant GBF marker features in the source text, the
mod2imp => imp2vs process would have preserved them.
Without looking again in
Hi David,
Please, send me the IMP file, I'll try to rebuild a module with
it.
I also need a TextSource value.
David Haslam writes:
The problem is that CrossWire no longer accepts module
submissions that use IMP format for the build process.
Best regards,
--
Dom
_
Is Ezra properly setting encoding on the content it renders? Is it maybe
setting a font that doesn't have the proper code points?
--Greg
On Sat, Jan 21, 2023, 13:12 Tobias Klein wrote:
> Hi Kristof, David,
>
> Adding Encoding=UTF-8 to the module conf file ~/.sword/mods.d/finpr.conf
> does not s
Hi Kristof, David,
Adding Encoding=UTF-8 to the module conf file ~/.sword/mods.d/finpr.conf
does not solve my issue.
The text still looks the same as before ...
What else could I do to further debug this?
Best regards,
Tobias
On 1/21/23 5:18 PM, Kristof Szabo wrote:
Hi Thomas,
I suppose t
Please note that besides FinPR, there are 54 other modules without
a valid Encoding value, among them:
[GreekHebrew] Lang=grc
[HebrewGreek] Lang=he
[KLV] Lang=tlh
[KLVen_iklingon] Lang=tlh
[KLViklingon_en] Lang=tlh
[ManxGaelic] Lang=gv
[Maori] Lang=mi
[Rieger] Lang=de
[ScotsGaelic] Lang=gd
[S
@Thomas
I'd help :) I have some time now, but ezra doesn't install either on my
Chromebook Debian or on my Ubuntu laptop, so my wisdom ends here... all you
need to do is to update locally the conf file with encoding info, check if
this fixes the issue, if yes, submit a new module config to Dom, if
Hi Kristóf,
The FinPR module is over ten years old, well before Dominique took on his
active role in the modules team. He would probably not have the original OSIS
XML file that was used to build the module.
The script he developed to rebuild a .conf file (in the current release
process) requi
On 1/21/23 12:08, Kristof Szabo wrote:
changing libsword
But no change should be needed. As has been observed, both Xiphos and
PocketSword display FinPR correctly in its current state (which I've
just confirmed).
Why are they successful and Ezra is not?_
>From my perspective this is a typical ¯\_(ツ)_/¯ situation, the
specification speaks clearly, from my point of view changing the module
configurations is easier (and less disruptive) than changing libsword.
Just comes to my mind: Dom has a conf generator for modules, which he uses
when new modul
On 1/21/23 11:18, Kristof Szabo wrote:
if there is nothing specified Latin-1 is the default
At ths point, I think Latin-1 is a poor default. UTF-8 should be assumed
in the absence of something specific.
I have 842 modules in place, of which 746 have Encoding=UTF-8, and no
module has any other
Hi Thomas,
I suppose the problem is that finpr.conf contains no encoding information
(check the Hun* modules for reference), and if there is nothing specified
Latin-1 is the default. mod2osis (shouldn't be used !! :)) shows that the
module is in UTF-8, so there is a misalignment.
https://wiki.cro
Hi Thomas,
What about other Finnish modules?
eg. FinPR92, FinRK, FinSTLK2017
Presumably you already tested (eg) German modules and found that umlauts and
eszett are both rendered aright?
Btw. FinPR renders aright in PocketSword (iOS/iPadOS).
David
Sent from Proton Mail for iOS
On Sat, Jan 21
Hi,
When retrieving the text of the FinPR module I am getting some rendering
issues with the Finnish Umlauts. This is based on a user's problem report.
Romans 5:8 returns like this in node-sword-interface / Ezra:
Mutta Jumala osoittaa rakkautensa meit� kohtaan siin�, ett� Kristus, kun
me vi
20 matches
Mail list logo
