Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Japanese kanji are not Japanese #1909

Closed
2 tasks done
jernejp21 opened this issue Mar 15, 2020 · 5 comments · Fixed by #2011
Closed
2 tasks done

Japanese kanji are not Japanese #1909

jernejp21 opened this issue Mar 15, 2020 · 5 comments · Fixed by #2011
Labels
bug broken functionality, usability problems, unexpected errors desktop Desktop client related issues state:tested We tested it and are about to release it
Milestone

Comments

@jernejp21
Copy link

jernejp21 commented Mar 15, 2020

  • This is not a feature request (existing functionality does not work, not missing functionality).
    I will request features on forum or via support.
  • I've searched and did not find a similar issue.

Describe the bug
When writing in Japanese, kanji are changed. Also comma after kanji is placed in weird position. In previous versions this was working. In mobile and web application this is shown correctly.

To Reproduce
Steps to reproduce the behaviour:

  1. Type this string: "背中、"
  2. Here, the font is correct.
  3. Please see picture below how this looks in desktop version. You will see that the first set (before comma) is different and comma is in the middle of text.

Expected behavior
If you save draft and open with web application, it will be displayed correctly.

Screenshots
slika

Desktop (please complete the following information):

  • OS: windows 10
  • Version 3.69.2
@jernejp21 jernejp21 added bug broken functionality, usability problems, unexpected errors desktop Desktop client related issues labels Mar 15, 2020
@charlag
Copy link
Contributor

charlag commented Mar 16, 2020

Hi
Do you remember in which version it worked correctly?

@jernejp21
Copy link
Author

I think in previous Desktop released version it still worked. Previous or 2 before 3.69.2.

@vitoreiji
Copy link
Contributor

It looks like the Windows desktop client renders the characters using the "Microsoft JhengHei UI", whereas Chrome, for example, used SimSun on my test machine. This explains why the problem is Windows specific.

I don't know if this font is doing it the right way for some other context, for example, maybe that would be the correct thing to display for traditional Chinese text? See the Unicode Han Unification.

@jernejp21
Copy link
Author

Is this automatic process or can you specify which font to use? Windows have by default installed MS Gothic font for Japanese.

Or would be easier to implement font selection in Desktop client? The same way as Outlook or Thunderbird have font selection option.

@ganthern ganthern added this to the Next next release milestone Apr 9, 2020
@bedhub bedhub modified the milestones: 3.71.5, Next next release Apr 16, 2020
@ganthern
Copy link
Contributor

related: electron/electron#18829

ganthern added a commit that referenced this issue Apr 20, 2020
adds an "override default font" option to the desktop settings viewer
which doesn't show up when there are no overrides configured for the
current platform (currently, contains SimHei's latin and chinese name on
windows, which is installed by default).

Uses a fixed list of fonts because getting a list of installed fonts
cross-platform requires a native module like font-manager or parsing of
platform-dependent command output (which may be huge)

This is not applied automatically because it replaces the default font
of the application and we can't rely on locale to detect which font
would be correct for the user.

changing the font list in main-styles.js directly would also work, but
that's not very extensible should this problem occur with other
language/locale/platform combinations. It would also require to get the
user's choice from the main thread somehow.
@ganthern ganthern linked a pull request Apr 20, 2020 that will close this issue
charlag pushed a commit that referenced this issue Apr 21, 2020
adds an "override default font" option to the desktop settings viewer
which doesn't show up when there are no overrides configured for the
current platform (currently, contains SimHei's latin and chinese name on
windows, which is installed by default).

Uses a fixed list of fonts because getting a list of installed fonts
cross-platform requires a native module like font-manager or parsing of
platform-dependent command output (which may be huge)

This is not applied automatically because it replaces the default font
of the application and we can't rely on locale to detect which font
would be correct for the user.

changing the font list in main-styles.js directly would also work, but
that's not very extensible should this problem occur with other
language/locale/platform combinations. It would also require to get the
user's choice from the main thread somehow.
ganthern added a commit that referenced this issue Apr 28, 2020
adds an "override default font" option to the desktop settings viewer
which doesn't show up when there are no overrides configured for the
current platform (currently, contains SimHei's latin and chinese name on
windows, which is installed by default).

Uses a fixed list of fonts because getting a list of installed fonts
cross-platform requires a native module like font-manager or parsing of
platform-dependent command output (which may be huge)

This is not applied automatically because it replaces the default font
of the application and we can't rely on locale to detect which font
would be correct for the user.

changing the font list in main-styles.js directly would also work, but
that's not very extensible should this problem occur with other
language/locale/platform combinations. It would also require to get the
user's choice from the main thread somehow.
@bedhub bedhub modified the milestones: 3.73.0, Next Next Release Apr 30, 2020
ganthern added a commit that referenced this issue May 5, 2020
adds a function getFonts() to main-styles.js that returns the
font-family string for the body style.

will add additional fonts depending on the platform and used language.

AppearanceSettingsViewer will now also cause a regeneration of the
style tags and a change of language on the native side when the language
is changed by the user.
ganthern added a commit that referenced this issue May 12, 2020
adds a function getFonts() to main-styles.js that returns the
font-family string for the body style.

will add additional fonts depending on the platform and used language.

AppearanceSettingsViewer will now also cause a regeneration of the
style tags and a change of language on the native side when the language
is changed by the user.
ganthern added a commit that referenced this issue May 12, 2020
adds a function getFonts() to main-styles.js that returns the
font-family string for the body style.

will add additional fonts depending on the platform and used language.

AppearanceSettingsViewer will now also cause a regeneration of the
style tags and a change of language on the native side when the language
is changed by the user.
ganthern added a commit that referenced this issue May 12, 2020
adds a function getFonts() to main-styles.js that returns the
font-family string for the body style.

will add additional fonts depending on the platform and used language.

AppearanceSettingsViewer will now also cause a regeneration of the
style tags and a change of language on the native side when the language
is changed by the user.
ganthern added a commit that referenced this issue May 19, 2020
adds a function getFonts() to main-styles.js that returns the
font-family string for the body style.

will add additional fonts depending on the platform and used language.

AppearanceSettingsViewer will now also cause a regeneration of the
style tags and a change of language on the native side when the language
is changed by the user.
charlag added a commit that referenced this issue May 26, 2020
@mpfau mpfau added the state:tested We tested it and are about to release it label Jun 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug broken functionality, usability problems, unexpected errors desktop Desktop client related issues state:tested We tested it and are about to release it
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants