Content declaration bug

[dreamingsky]

I found a bug with the content declarations.  The declaration for Content02 is using the declaration for Content01.

I'd like Content01 as black font with italics.
I'd like Content02 as blue font and no italics.

language2NumberOfContentDeclarations=02
language2Content01DisplayText=Italics
language2Content02DisplayText=Pinyin

language2Content01FontStyle: italic
language2Content02FontColour=0,0,255

But, Content02 is actually showing as black font with italics.

If I change Content2 to Content1, then Content2 shows the blue font OK:

language2NumberOfContentDeclarations=02
language2Content01DisplayText=Italics
language2Content02DisplayText=Pinyin

language2Content01FontColour=0,0,255
language2Content02FontStyle: italic

[Gert]

Thanks for that report and for the attached material !!

I will look at that ... however it will take a while.

Best regards,
Gert

[Gert]

Jeff,

I just was trying to reproduce your bug: and I was successful in doing so 

Ok, something for me to debug 

Thanks for your report !
Gert

[Gert]

I just was trying to reproduce your bug: and I was successful in doing so

Correction: it is not a bug.

Here is what happens - well it is really a little complicated ...

DictionaryUpdateCEDICTChi.updateDictionaryExpression does write the content number for Pinyin hard-coded as 1:

Code Select Expand

updatedExpression = DictionaryUpdateLib.setContentPronounciation(updatedExpression, 1);
(remark: the 2nd parameter is the content number)
In the generated dictionary file it has [01 instead of [02 !

Well, it is really written for entries such as
    * The input looks like
    * 安康 安康 [01an1 kang1],good health
    * [01 is the start content delimiter


Hmmm, so I guess DictionaryUpdateCEDICTChi should be updated so that it scans the content number following the [-character and uses it in the call to DictionaryUpdateLib.setContentPronounciation ?

Hmmmm, or as short-term solution you might simply switch the content numbers, so that Pinyin is content number 1; that should solve your problem too.

Hmmmmmmm, with the current implementation of DictionaryUpdateCEDICTChi only 1 content will be possible; cause it scans for the [-character and expects a Pinyin pronunciation between the [01 and the ]. Well, so if you intend to use additional contents, then the scan should be more specific (e.g. for [01, or ... whatever you like).

Regards,
Gert

[dreamingsky]

I changed the content declaration from 03 to 01.  Everything works OK now.  This should be fine.  The Chinese half only needs 1 content declaration.  The other language half can still use multiple declarations.

Thanks for your help
Jeff

[Gert]

Ok.

Well, just let me know if I should occasionally change the scan for [ to [01 (or whatever else you would like).

Best regards,
Gert

[Gert]

Oh, and one more remark: I think there is always implicitely the content number 0, which is applied to that text which has no content assigned, i.e. is not within [xx ]. It should be able to change the attributes of that content number 0 with statements like

Code Select Expand

language2Content00FontStyle: italic


Well, I would have to look at that more to understand whether it is true what I write here 

Adding a scan for [01 will be done rather quickly, let me know if that helps you.

Gert

[dreamingsky]

Scanning for "[01" instead of "[" would be useful.  I'd actually like 2 declarations for Chinese:
1. traditional Chinese (black - no declaration)
2. simplified Chinese (dark red)
3. pinyin (dark blue)

I can keep pinyin as "[01" and use "[02" for simplified Chinese.

Also, originally in the CEDICT dictionary there was no space after "[01" (example: [01tuo1 ci2]).  Personally I like a space after the "[01" (example: [01 tuo1 ci2]).  Currently [01 tuo1 ci2] works OK.  If you make changes to DictionaryUpdateCEDICTChi, can you please keep the option to use a space after "[01"?

There's no rush for the code fix.  Thanks for your help
Jeff