D25339: KateRenderer: Use representitive character in CJK to estimate the fontHeight.

[Shinjo Park]

pshinjo added a comment.


  In D25339#663833 , @rjvbb wrote:
  
  > doesn't it give you US-ASCII canonical representations of every possible 
glyph?
  
  
  Whether it is possible or not, no CJK users will write TeX document using 
US-ASCII representation for all glyphs instead of their native alphabet, 
especially when the document is in their mother tongue. Welcome to the world of 
transliteration problems.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D25339

To: xuetianweng, #ktexteditor, cullmann, dhaumann, #frameworks, rjvbb
Cc: sars, pshinjo, rjvbb, fakefred, anthonyfieroni, kde-frameworks-devel, 
kwrite-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, 
demsking, cullmann, dhaumann

D25339: KateRenderer: Use representitive character in CJK to estimate the fontHeight.

[Shinjo Park]

pshinjo added a comment.


  In D25339#663462 , @rjvbb wrote:
  
  > This patch is only needed when mixing a main Latin1 (like) alphanumeric 
font with occasional glyphs from a font that have a different, taller height?
  
  
  Yes, though the "occasion" will highly depend on the user locale. For someone 
this will likely never happen, for someone this will happen everyday.
  
  > Am I right that any text that uses only a single font will see some form of 
significant loss of the number of lines that fit within a given vertical space?
  
  Yes, given that the font contains all required glyphs to represent the string 
"AHIygあ你말" is limited. That's also visible in my test 2. Previous tests were 
done in artificially high font size (32pt for example) and less dense texts so 
the original authors might overlooked this problem.

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D25339

To: xuetianweng, #ktexteditor, cullmann, dhaumann, #frameworks, rjvbb
Cc: pshinjo, rjvbb, fakefred, anthonyfieroni, kde-frameworks-devel, 
kwrite-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann

D25339: KateRenderer: Use representitive character in CJK to estimate the fontHeight.

[Shinjo Park]

pshinjo added a comment.


  In D25339#563370 , @xuetianweng 
wrote:
  
  > And what I'd like to point is, for CJK users, it is uncommon for them to 
select a single font to cover all the characters, because such fonts are really 
rare. People usually select one latin only font and just let system 
(fontconfig) select the fallback for them.
  
  
  This statement is valid even for non-CJK users who only occasionally see the 
said characters.
  
  For all screenshots, left hand side is git master+this patch, right hand side 
is Kate 19.12.3/Frameworks 5.68.0 on Ubuntu 20.04.
  
  Test 1 - Hack + Noto Sans Mono CJK KR 9pt (Hack does not contain CJK glyphs, 
so for missing glyphs the latter will be used). Notice that only in the left 
hand side the underline in my e-mail address is visible:
  
  F8284453: Screenshot_20200504_210144.png 

  
  Test 2 - Nanum Square 9pt (contains both Latin-1 and Korean glyphs):
  
  F8284455: Screenshot_20200504_210313.png 

  
  Test 3 - Ubuntu Mono + Noto Sans Mono CJK KR 9pt. For me the right hand side 
is a regression, since neither Cyrillic nor Korean scripts are clearly visible 
when both of them are in the same line. Also in this setup most of Korean texts 
are cut by half even when there are only Korean texts. Compare it with the 
other lines where only Cyrillic is visible:
  
  F8284485: Screenshot_20200504_213506.png 

  
  I can also confirm about 6-7 lines of loss, but for me the right hand side 
has issues. Need to find some compromise.

INLINE COMMENTS

> katerenderer.cpp:1040
>  m_fontHeight = qMax(1, qCeil(m_fontMetrics.ascent() + 
> m_fontMetrics.descent()));
> +// Try to use representitve character from English, Chinese, Japanese
> +// and Korean to calculate the line height.

I think this causes the regression mentioned in

In D25339#663322 , @rjvbb wrote:

> I can't speak for the special cases where this change would improve matters, 
> but for me it introduces a clear regression (waste of vertical space: 12 
> lines less) in a basic ascii code editing context. Font used is Ubuntu Mono 
> 10pt.


But this part is the raison d'etre for this patch: provide enough font height 
for non-latin-1 text. Also not considered is glyphs from other scripts, such as 
Cyrillic, Arabic, ... What could be another solution?

REPOSITORY
  R39 KTextEditor

REVISION DETAIL
  https://phabricator.kde.org/D25339

To: xuetianweng, #ktexteditor, cullmann, dhaumann, #frameworks, rjvbb
Cc: pshinjo, rjvbb, fakefred, anthonyfieroni, kde-frameworks-devel, 
kwrite-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, 
demsking, cullmann, sars, dhaumann

KAcceleratorManager, Kirigami and accelerator key translations

[Shinjo Park]

Hello,

I have reported Bug #420488 and got to know that similar bugs have been 
reported such as #407386, #417467. This was supposed to be fixed by #406035 but 
the fix was not effective at all.

Inspired by this, I have checked how other languages are translating the 
accelerator keys and found this pattern:
- Languages using Latin, Cyrillic, Arabic (except Uyghur), Hebrew, Greek and 
some Indic scripts are placing accelerator keys within the translated message
- Languages using another Indic scripts, C/J/K are placing accelerator keys 
separate from the message (example: "New " is translated into "નવી 
વિન્ડો 
()", "ಹೊಸ ಕಿಟಕಿ()", "新建窗口()", "නව කවුළුව ()", "새 창()" in Gujarati, 
Kannada, Chinese Simplified, Sinhala, and Korean respectively)
- Source: https://l10n.kde.org/dictionary/compare-translations.php?
package=applications=dolphin.po=New+%26Window

To kde-i18n-doc: if I made some wrong assumptions, please correct them.

For the languages in the first list, I think KAcceleratorManager and Kirigami 
should work fine. For the languages in the second list, there are two problems: 
no accelerator keys are allocated in QWidget based applications when the 
translated string does not contain Latin alphabet within the string or 
followed by an ampersand. Also non typeable characters are misallocated 
accelerator keys in Kirigami based applications.

As a workaround for Kirigami displaying weird accelerator keys, I think 
extending the range of non-typeable characters to include abovementioned 
scripts can at least non-typeable accelerator keys from appearing:
https://cgit.kde.org/kirigami.git/tree/src/mnemonicattached.cpp#n92 However, 
this won't solve the problem that these strings won't have an accelerator key.

For the another problem of having no accelerator keys, I can think of two 
workarounds:
- Manually specify accelerator keys within the translated string. However, 
just by looking PO files I don't know which strings form a group, and some UI 
string which is supposed to have an accelerator key lacks of an accelerator 
key followed by an ampersand, so the suitable accelerator key has to be 
manually examined by translators.
- Allocate accelerator keys based on the original English string: That's what 
used by the current translations. I am not sure whether this workaround is 
possible in KDE Frameworks implementation (both KWidgetsAddons and Kirigami) 
wise or should be addressed in Qt.

I am looking for further opinions and inputs.

Best,
Shinjo

Re: Polish translation of "Cancel"

[Shinjo Park]

I wanted to avoid this topic because I don't know Polish language, but due to 
the comments in the said bug and this list, and my personal experience, I 
changed my mind.

2020년 4월 17일 금요일 오후 8시 31분 12초 CEST에 Łukasz Wojniłowicz 님이 쓴 글:
> > I also do not understand how this one word became a cause worth fighting
> > for.
> 
> For me it's a case of language correctness and purity.
> ...
> The thing is, that some people see this translation as "absurd", "invalid",
> "ancient" and I presume it is so because it's not what they've been
> accustomed to by the mainstream OS, which is Windows.

Back around 1990s the similar movement used to exist in Korea. The computer-
related words were primarily "imported" from English, and earlier computer 
users and experts tried to "purify" the terms which is not considered as 
proper Korean. However, that movement lost the motivation around late 1990s-
earlier 2000s as technologies were basically exponentially expanding, and most 
of the "purified" words created in earlier days are nearly nowhere to see in 
these days. As an example, one person tried to "purify" the Korean translation 
of Notepad++, using the words proposed around 1990s [1], and the community 
consensus was "reject" stating that these words are not mainstream anymore.

[1] https://github.com/notepad-plus-plus/notepad-plus-plus/pull/7935

I'm afraid that the history repeats itself. When Korean KDE translation was 
not properly maintained in mid 2000s, it used to contain some traces of 
linguistic purism from the past. That was one of the reason for Korean users 
avoiding KDE at that time. Personally, I think KDE is not the place to 
"promote" any kind of linguistic purism (or any other linguistic ideals), but 
rather "reflect the reality" only when it is a mainstream in the said language.

ps.

https://bugs.kde.org/show_bug.cgi?id=404286:
> I wonder why languages like: Ukrainian, Spanish, Catalan, Basque, Serbian,
> Greek, Turkish, Chinese, Korean, Arabic, Hebrew, Punjabi, and probably some
> others translated it differently.

Korean language is not using Latin alphabet as a primary script, and the term 
"OK" as a standard dialog button was translated even before I started using 
computer.

Maintenance status of KMid?

[Shinjo Park]

Hi,

I'd llike to ask whether KMid is maintained or not:
- No release/significant commit since 2010
- Already mentioned as "unmaintained" in a bug 359424 [1]
- Still not migrated to git/KF5 yet

[1] https://bugs.kde.org/show_bug.cgi?id=359424

Best regards,
Shinjo