(background/environment) f30; Gnome The problem is seen in the Gnome terminal editor, but not in gvim, Firefox, or Thunderbird. The terminal's font is set to the system font (vs. custom font). The system font is set to "AR PL UKai CN Book 16". This is set via the "Tweaks" tool. I really do need to use the UKai font.
(what I do) When I view a Chinese music video in youtube, I also make notes about it in a text file. I use vi(m) to edit that file. 1. In Firefox, I load a youtube video whose title and/or description (poster's comments) contains Chinese text. This text is found below the video itself, and above the section for comments by viewers. 2. Using the trackball (cursor), I select the text containing Chinese characters. 3. I paste the selected text into the left part of google translate. - Below the Chinese text that I pasted in, google translate displays "pinyin" (the "romanization" of the Chinese text). This is useful for pronunciation. - In the right part of google translate, google translate shows its English translate guess. 4. Using the trackball (cursor), I select the pinyin, and paste it into my text file of notes about the video. 5. Using the trackball (cursor), I select the English translation guess, and paste it into my text file of notes about the video.
(what I see) When the Chinese text contains the Chinese equivalent of the open double quote (it looks like a double version of the less-than character '<'), then in my notes file, in the pinyin and English, it shows as an open double quote with the next English character in the same position (that is, on top of each other). There is no problem with close double quotes. I have not seen this problem with any other character. I've attached an example text file, and a screen capture of that text file in vi(m). Notice in the screen capture: - in the second non-blank line, after "13", an open double quote and the letter 'Y' appear to be in the same position. - in the third non-blank line, after "13 ", an open double quote and the letter 'I' appear to be in the same position. This problem occurs a lot, and it does make editing difficult.
(the question) My sense is that this is not something that I can fix on my workstation. So I should submit a bug. Where should I submit the bug, and against what (the font or the terminal or something else (what?))?
On 2/26/20 9:33 AM, home user wrote:
(the question) My sense is that this is not something that I can fix on my workstation. So I should submit a bug. Where should I submit the bug, and against what (the font or the terminal or something else (what?))?
Is it only if you use that font? Can you copy and paste the characters into your reply here so we can see the actual codes?
(On 2/26/20 12:35 PM, Samuel wrote:)
Is it only if you use that font?
I don't know. Because I'm working with a mix of Chinese, pinyin, and English, I only use Kai fonts. I have trouble seeing/reading with the other kinds of fonts that support Chinese.
Can you copy and paste the characters into your reply here so we can see the actual codes?
My original post has the attachment quote2_bug.txt that has the characters (pasted from google translate). If you're wanting something different/else, where are you wanting me to copy from: google translate or the attached text file?
On 2/26/20 11:56 AM, home user wrote:
(On 2/26/20 12:35 PM, Samuel wrote:)
Is it only if you use that font?
I don't know. Because I'm working with a mix of Chinese, pinyin, and English, I only use Kai fonts. I have trouble seeing/reading with the other kinds of fonts that support Chinese.
Can you copy and paste the characters into your reply here so we can see the actual codes?
My original post has the attachment quote2_bug.txt that has the characters (pasted from google translate). If you're wanting something different/else, where are you wanting me to copy from: google translate or the attached text file?
Sorry, I didn't notice that attachment. I don't see that problem in the text editor. I'm wondering how you got that font in the terminal, since usually that will only accept monospace fonts. So there must be some interaction going on in there, but I wasn't going to switch my system font to test it. I don't have any suggestions.
(On 2/26/20 1:12 PM, Samuel wrote:)
I don't see that problem in the text editor. I'm wondering how you got that font in the terminal,...
Hmmm... When I launch "Text Editor" (not the Gnome Terminal), and load my file, I do *not* see the problem (same as you). Bringing up Preferences and looking at the Font & Colors tab, I see in the Font section "Use the system fixed width font (AR PL UKAI CN 16)" checked.
So my suspicion that the problem is in the font is wrong.
On 2020-02-27 01:33, home user wrote:
The system font is set to "AR PL UKai CN Book 16". This is set via the "Tweaks" tool. I really do need to use the UKai font.
Not being a Gnome user, could you tell me what you mean by "sytem font"?
In the tweaks tool, under fonts, I see "Interface text", "Document Text", etc. But no "system text".
(On 2/26/20 2:16 PM, Ed wrote:)
Not being a Gnome user, could you tell me what you mean by "sytem font"? In the tweaks tool, under fonts, I see "Interface text", "Document Text", etc. But no "system text".
All four fonts in the Tweaks tool .. Interface Text Document Text Monospace Text Legacy Window Titles are set to AR PL UKai CN Book 16.
I assume that, in the Gnome Terminal preferences, when "custom font" (in the Text tab) is unchecked, that it's using whatever the Tweaks Monospace Text is set to. Past experimentation supports my assumption.
On 2020-02-27 07:12, home user wrote:
(On 2/26/20 2:16 PM, Ed wrote:)
Not being a Gnome user, could you tell me what you mean by "sytem font"? In the tweaks tool, under fonts, I see "Interface text", "Document Text", etc. But no "system text".
All four fonts in the Tweaks tool .. Interface Text Document Text Monospace Text Legacy Window Titles are set to AR PL UKai CN Book 16.
I assume that, in the Gnome Terminal preferences, when "custom font" (in the Text tab) is unchecked, that it's using whatever the Tweaks Monospace Text is set to. Past experimentation supports my assumption.
I think you are saying that the character 《 is involved?
But what if you have a file containing just “Y?
On 2020-02-27 05:08, Ed wrote:
I think you are saying that the character 《 is involved?
Correct.
But what if you have a file containing just “Y?
I assume that you mean an upper case 'Y' not immediately preceded by an open double quote. The file that I provided in the original post contains in the second not-empty line 'g'-space-'Y'. No problem. Notice the problem does show in the third non-empty line with the open double quote followed by upper case 'I'. I tried upper case 'I' not immediately preceded by the open double quote; no problem.
By the way, let's all be clear that open double quote (not on the keyboard) is *not* the same the simple double quote (shift - single quote), which is on the keyboard just to the right of the colon/semicolon key.
Question: I recall seeing in the fedora web site some time ago (release notes? plans for a future release?) that Fedora will be switching to google (noto?) fonts. I did not see a Kai font in that set. Will that font set include a Kai font?
I'm off to an evening appointment. another appointment tomorrow morning. I'll resume this tomorrow evening.
On 2020-02-27 08:50, home user wrote:
On 2020-02-27 05:08, Ed wrote:
I think you are saying that the character 《 is involved?
Correct.
But what if you have a file containing just “Y?
I assume that you mean an upper case 'Y' not immediately preceded by an open double quote. The file that I provided in the original post contains in the second not-empty line 'g'-space-'Y'. No problem. Notice the problem does show in the third non-empty line with the open double quote followed by upper case 'I'. I tried upper case 'I' not immediately preceded by the open double quote; no problem.
By the way, let's all be clear that open double quote (not on the keyboard) is *not* the same the simple double quote (shift - single quote), which is on the keyboard just to the right of the colon/semicolon key.
Question: I recall seeing in the fedora web site some time ago (release notes? plans for a future release?) that Fedora will be switching to google (noto?) fonts. I did not see a Kai font in that set. Will that font set include a Kai font?
I'm off to an evening appointment. another appointment tomorrow morning. I'll resume this tomorrow evening.
No, I don't mean just an uppercase Y.
Do this command in a terminal. I'm assuming the command base64 exists on your system.
echo 4oCcRWQNCg== | base64 -d > Ed
Then cat the file Ed
It should be
[egreshko@meimei Char]$ cat Ed “Ed
But I think on your system it will not be that way.
On 2020-02-27 10:12, Ed Greshko wrote:
No, I don't mean just an uppercase Y.
Do this command in a terminal. I'm assuming the command base64 exists on your system.
echo 4oCcRWQNCg== | base64 -d > Ed
Then cat the file Ed
It should be
[egreshko@meimei Char]$ cat Ed “Ed
But I think on your system it will not be that way.
FWIW, I believe this will end up being a NOTABUG.
I'm pretty sure that gnome-terminal, like konsole, is expecting that the fonts being used are monospace. As you can see, if you use Custom Fonts in gnome-terminal there is no option to select AR PL UKai CN Book.
In the case of konsole, you also can't directly select AR PL UKai CN Book. But, if you check the box that says "Show all fonts" you will get a warning message about potential display issues.
As a matter of fact, if one forces AR PL UKai CN Book similar issues do show with the UTF-8: 0xE2 0x80 0x9C character as is the case with the sample provided.
So, forcing a non-monospace font in gnome-tweaks is a bad idea. If anything, you should consider writing a bugzilla against gnome-tweaks which asks that it limit the font choices for "monspace text" to actual monospace fonts.
On 2020-02-27 9:54 PM, Ed Greshko wrote:
(AR PL UKai CN Book, monospace fonts, terminals, system fonts, Tweaks)
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So 1. Why does AR PL UKai CN Book not qualify as a monospace font? 2. What does qualify a font as monospace?
In Konsole, in the file "Ed" that you asked me to create in an earlier message, the open double quote does not show. But if I add a space between the open double quote and the 'E', the open double quote will show.
On 2020-02-28 07:42, home user wrote:
On 2020-02-27 9:54 PM, Ed Greshko wrote:
(AR PL UKai CN Book, monospace fonts, terminals, system fonts, Tweaks)
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So
- Why does AR PL UKai CN Book not qualify as a monospace font?
- What does qualify a font as monospace?
Sadly, my knowledge of fonts is limited. So, I can't answer your question.
I'll just say that AR PL UKai CN Book is troublesome when used in a terminal program. So, don't use it in a terminal program.
On Thu, 2020-02-27 at 16:42 -0700, home user wrote:
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So
- Why does AR PL UKai CN Book not qualify as a monospace font?
Just wondering: Does the font include Roman characters, as well? Or is your example combining Roman characters from one font, and the Eastern characters from another?
- What does qualify a font as monospace?
Theoretically, a font should identify itself as such (so that other software can filter out/in monospace fonts from font selection choices), and its creator should accurately describe their font.
It's not unknown for fonts to be faulty (three examples below). That can be immediately obvious when a glyph is badly drawn, but less obvious with metadata.
I used to use MG Open Modata in a website name logo, because it looked nice and was easy to read. However, it's numerals are crap. They're oddly spaced. The inter-character kerning, and the width of some individual characters, are all wrong.
Anyone who uses circuit diagrams is probably familiar with seeing something that's Chinese or Japanese, and their own language looks beautifully printed, but any Roman characters are typed like they came from a mangled typewriter. There'll be some letters shoved too far to the left or right, maybe even overlapping, or differently sized.
Trying to put musical flat signs into text is next to impossible. Every font I've tried that has them puts a stupid fat space left of the flat sign. Music scoring software uses its own internal kludges to change the intercharacter spacing of a bad font, rather than supply a decent font. Without that kludge, trying to type E flat, for instance, had a whacking great big space (where none belongs) between the letter E and the flat sign, where you haven't even typed any blank spaces. And some music scoring overcompensates, so you end up with the flat sign starting to overlap the edge of the E, and looks almost like you'd typed B flat.
On 2020-02-28 16:43, Tim via users wrote:
On Thu, 2020-02-27 at 16:42 -0700, home user wrote:
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So
- Why does AR PL UKai CN Book not qualify as a monospace font?
Just wondering: Does the font include Roman characters, as well? Or is your example combining Roman characters from one font, and the Eastern characters from another?
It has an extensive range.
https://fontinfo.opensuse.org/fonts/ARPLUKaiCNBook.html
And, FWIW, using fontforge it classifies itself as Modern Proportional.
On 2020-02-27 10:57 PM, Ed wrote:
Do this command in a terminal. I'm assuming the command base64 exists on your system. echo 4oCcRWQNCg== | base64 -d > Ed Then cat the file Ed
4oCcRWQNCg==? Wow. How did you come up with that?! I get the open double quite into my comment files by copying it from google translate. Same with close double quotes and vowels (both lower and upper case) with tone marks. What is the better way? Same question with 'u' and 'U' with the two dots above. More difficult: 'u' or 'U', with the two dots above *and* tone marks.
Your prediction is correct; I see the open double quote and the 'E' in the same position.
On 2020-02-28 07:02, home user wrote:
On 2020-02-27 10:57 PM, Ed wrote:
Do this command in a terminal. I'm assuming the command base64 exists on your system. echo 4oCcRWQNCg== | base64 -d > Ed Then cat the file Ed
4oCcRWQNCg==? Wow. How did you come up with that?! I get the open double quite into my comment files by copying it from google translate. Same with close double quotes and vowels (both lower and upper case) with tone marks. What is the better way? Same question with 'u' and 'U' with the two dots above. More difficult: 'u' or 'U', with the two dots above *and* tone marks.
The command base64 either encodes or decodes. Without the -d means encode. So,
echo "whatever string" | base64
gets you the encoded value.
The "better way" is if you really need the "AR PL UKai CN Book 16" font is to use a real text editor.
But, if you will be looking at the text mostly in a terminal, then find a monospace font you can live with.
Your prediction is correct; I see the open double quote and the 'E' in the same position.
I had no doubt.
On 2020-02-28 04:11, Ed wrote:
The "better way" is if you really need the "AR PL UKai CN Book 16" font is to use a real text editor. But, if you will be looking at the text mostly in a terminal, then find a monospace font you can live with.
The text is all originally in .txt files; such files I view in a terminal. Some of the text (Chinese, pinyin, and English) in the .txt files are copied from to make html (.html) files and javascript (.js) files. I use vim to create and edit those, too; the results (private web pages) are viewed in Firefox.
vim seems to me to be a quite powerful editor. What is considered a "real text editor"?
On 2020-02-28 10:55, home user wrote:
On 2020-02-28 04:11, Ed wrote:
The "better way" is if you really need the "AR PL UKai CN Book 16" font is to use a real text editor. But, if you will be looking at the text mostly in a terminal, then find a monospace font you can live with.
The text is all originally in .txt files; such files I view in a terminal. Some of the text (Chinese, pinyin, and English) in the .txt files are copied from to make html (.html) files and javascript (.js) files. I use vim to create and edit those, too; the results (private web pages) are viewed in Firefox.
First of all, a file with a .txt is meaningless in a general sense.
[egreshko@meimei ~]$ file Death-Cert.jpeg Death-Cert.jpeg: JPEG image data, JFIF standard 1.01, resolution (DPI), density 600x600, segment length 16, baseline, precision 8, 5100x7016, components 1 [egreshko@meimei ~]$ cp Death-Cert.jpeg Death-Cert.txt [egreshko@meimei ~]$ file Death-Cert.txt Death-Cert.txt: JPEG image data, JFIF standard 1.01, resolution (DPI), density 600x600, segment length 16, baseline, precision 8, 5100x7016, components 1
vim seems to me to be a quite powerful editor. What is considered a "real text editor"?
The issue, as I see it, you want to use "AR PL UKai CN Book 16" when you edit text that will eventually become part of a web page. (I assume your html code is also telling the browser to use that font?). Unfortunately, that font has issues in a terminal. So, what to do?
The choices I see are....
1. Pick a font that works in the terminal which you can tolerate. 2. Use "text-editor" as you've done in an earlier post in this thread. Even libreoffice writer can save in pure "text" format. 3. Use a html editor or creator or whatever they are called. libreoffice claims to have that ability. to directly create your web page.
On Fri, 2020-02-28 at 11:17 +0800, Ed Greshko wrote:
- Use a html editor or creator or whatever they are called.
libreoffice claims to have that ability. to directly create your web page.
It creates absolutely dire HTML that needs to be fixed up, afterward. Best avoided.
On 2020-02-28 16:28, Tim via users wrote:
On Fri, 2020-02-28 at 11:17 +0800, Ed Greshko wrote:
- Use a html editor or creator or whatever they are called.
libreoffice claims to have that ability. to directly create your web page.
It creates absolutely dire HTML that needs to be fixed up, afterward. Best avoided.
OK, good to know. Their "claims" are exaggerated. :-)
Sounds as if you have some experience in that area? If so, what, if anything would you suggest.
Or is it still the case that hardcore html coders do it sans "assistance"?
Tim:
It creates absolutely dire HTML that needs to be fixed up, afterward. Best avoided.
Ed Greshko:
OK, good to know. Their "claims" are exaggerated. :-)
Sounds as if you have some experience in that area? If so, what, if anything would you suggest.
Or is it still the case that hardcore html coders do it sans "assistance"?
In my case, yes. I use gvim. I have some macros to make things a bit easier (such as pressing F8 to close a tag on an element, for me). And a few special character shortcuts. But as to what code goes where, that's entirely up to me.
While you can get away with the mess created by a basic HTML coder like LibreOffice for a webpage (ignoring its crappiness, or post-process it), you really want something better for working on a web *site*. With a site you could do with something that handles the cross-linking between pages for you, that allows common style sheets to be applied (and be easily customisable) for all pages in one go, rather than splattering individual styling choices throughout each document.
I found that to do it properly, you needed to understand so much about forcing your software into compliance, that it was far easier to just do it all by hand, properly, in the first place.
These days, it's quite common for people to use webmastering packages (WordPress, etc) that are integrated with their webserver.
However, I don't. They come with a *lot* of security failure issues, and you're locked into their templates. Which are choice limiting, and involves a lot of form-filling to create content with any structured meaning. So that's endless browsing for a template you can live with, or just making do. And, then, lots of having to type something, then metadata it into usefulness, all over the page, is far worse (for me) than to just hand code it.
The security issues being another nail in the coffin. It requires eternal vigilance to keep on top of continual updates (remembering their websites are a big database using a lot of coding features). You need to understand the issues to be able to handle them. Blind faith doesn't do the job.
My server logs show continual (failed) hacking attempts. They fail because they're trying to find exploitable options in website managing software that I don't have installed on my webserver. All I have to contend with is stuff-ups by my host fiddling with their own software (doing backups and restores without telling us, and screwing up file permissions on every file on the site, sending DNS record serial numbers backwards; swapping Apache for LightSpeed, which doesn't replace all the features that Apache has, etc). I'm sure they don't adequately keep things like WordPress, et al, site daily up-to-date, either.
On 2020-02-28 22:49, Tim via users wrote:
In my case, yes. I use gvim. I have some macros to make things a bit easier (such as pressing F8 to close a tag on an element, for me). And a few special character shortcuts. But as to what code goes where, that's entirely up to me.
<snip>
All of that was very good info. Thanks for taking the time.
It may not be applicable to the OP however since he did indicate what he produces is for private consumption. It didn't sound as if he is interested in getting heavy into html design.
On Thu, 27 Feb 2020 16:02:45 -0700 home user mattisonw@comcast.net wrote:
On 2020-02-27 10:57 PM, Ed wrote:
Do this command in a terminal. I'm assuming the command base64 exists on your system. echo 4oCcRWQNCg== | base64 -d > Ed Then cat the file Ed
I get:
cat Ed “Ed
D
On 2020-02-28 07:02, home user wrote:
How did you come up with that?!
Oh, I think I answer the wrong question.
I sent the text as base64 encoded so avoid any issues with copy/paste or potential munging.
I generally don't deal with European languages so I'm not familiar with input methods.
FWIW, as a "test", I actually used my Android phone to create the text “Ed. Using the Taiwan keyboard one can select "Sym" and choose symbols from of either Chinese or English variety.
I knew your quote.txt file contained the 0xE2 0x80 0x9C character and wanted to check if the phone would do the same.
On 2020-02-27 08:50, home user wrote:
By the way, let's all be clear that open double quote (not on the keyboard) is *not* the same the simple double quote (shift - single quote), which is on the keyboard just to the right of the colon/semicolon key.
Yes, of course. That is UTF-8: 0x22 while the similar looking character is UTF-8: 0xE2 0x80 0x9C.
On 2020-02-28 06:14, Ed wrote:
On 2020-02-28 07:42, home user wrote:
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So
- Why does AR PL UKai CN Book not qualify
as a monospace font? 2. What does qualify a font as monospace?
Sadly, my knowledge of fonts is limited. So, I can't answer your question.
Anyone else? My questions are not just out of curiosity.
On 2/27/20 7:01 PM, home user wrote:
On 2020-02-28 06:14, Ed wrote:
On 2020-02-28 07:42, home user wrote:
I thought AR PL UKai CN Book is a monospace font. My understanding is that Chinese, Japanese, and Korean characters all fit in uniformly-sized squares, and this should be true of sans-serif fonts, Ming fonts, and regular fonts (includes AR PL UKai CN Book). So
- Why does AR PL UKai CN Book not qualify
as a monospace font? 2. What does qualify a font as monospace?
Sadly, my knowledge of fonts is limited. So, I can't answer your question.
Anyone else? My questions are not just out of curiosity.
A monospace font is marked as that in the font definition. I have no idea why the terminal is overlaying that character when the text editor does not.
(not really replying to any one specific post)
To clarify, my .txt files are not just intermediary storage between (youtube pages / google translate), and my .html/.js files. They also are storage for my notes (comments) that are not in my .html files, and I view the .txt files frequently for those notes.
I agree with Ed that the AR PL UKai... fonts include the Roman fonts. In the Gnome terminal (and thus vim), I use the one font for Chinese, Roman, punctuation, and special characters (vowels with marks over them, for pinyin). I don't think there's a way to mix the fonts. One pleasant surprise is that though the font is set to AR PL UKai CN Book (for "simplified Chinese), the terminal seems to properly handle "traditional" Chinese (the Taiwan script); the correct font for that should be AR PL UKai TW Book. It's correctly handling the mix of both the "simplified" Chinese and the "traditional" Chinese in the same file and even in the same line.
I've seen faults in fonts, too. In other fonts (I don't recall which), there are gaps. I can get vowels with first, second, and fourth tone marks above them, but not vowels with third tone marks above them. Sometimes they're displayed as blanks (Gnome terminal does this), sometimes they're displayed by borrowing the character from another font (Firefox does this).
Ed: I do indeed use the AR PL UKai fonts in Firefox.
I have in the past seen mainly negative comments on tools for creating web pages. Thus I use vim. Vim and gvim do help by providing syntax highlighting, some encloser matching, and some auto-indentation. My web pages exist only on my workstation, freeing me of security concerns. The web pages are static (have no behavior) other than javascript scripts that select pictures based on when the page is loaded (this quasi-randomizes what pictures decorate the page), and clickable links. Thus my web pages are simple compared to public/commercial ones. What's difficult about doing my web pages is handling the mix of three scripts (simplified Chinese, traditional Chinese, and Roman). I doubt that other tools will help with that.
I inadvertently replied off-list.
Below is my attempt to fix that with the reply from "home user" and my response. On 2020-02-29 06:04, home user wrote:
On 2/28/20 2:34 PM, Ed Greshko wrote:
On 2020-02-29 05:15, home user wrote:
I agree with Ed that the AR PL UKai... fonts include the Roman fonts. In the Gnome terminal (and thus vim), I use the one font for Chinese, Roman, punctuation, and special characters (vowels with marks over them, for pinyin). I don't think there's a way to mix the fonts. One pleasant surprise is that though the font is set to AR PL UKai CN Book (for "simplified Chinese), the terminal seems to properly handle "traditional" Chinese (the Taiwan script); the correct font for that should be AR PL UKai TW Book. It's correctly handling the mix of both the "simplified" Chinese and the "traditional" Chinese in the same file and even in the same line.
There is no way to mix fonts in a terminal.
My apologies for my bad wording. I did know that.
The terminal is *not* handling anything when it comes to traditional v.s. simplified.
The glyphs are different and thus the Unicode is different. For example....
內 U+5167 UTF-8: 0xE5 0x85 0xA7 Traditional 内 U+5185 UTF-8: 0xE5 0x86 0x85 Simplified
The font has included within it glyphs for both traditional and simplified. The terminal has no involvement.
Thank-you for the correction. So why are there two separate AR PL UKai fonts - the CN and the TW? What *is* the difference?
Well, that would require a comparison of the fonts.
However, I do know that there are terms/characters used and created in Taiwan which are not used in the PRC. So, it is possible that the TW font contains them and the CN not. The reverse is also possibly true. FWIW, the same holds true for HK.
But, I, for one won't be doing the comparison. :-)
On 2020-02-28 02:34 PM, Ed wrote:
So why are there two separate AR PL UKai fonts - the CN and the TW? What *is* the difference?
Well, that would require a comparison of the fonts. However, I do know that there are terms/characters used and created in Taiwan which are not used in the PRC. So, it is possible that the TW font contains them and the CN not. The reverse is also possibly true. FWIW, the same holds true for HK.
I had read that before, and since forgotten. What Ed said completely answers my two questions about the 2 AR PL UKai fonts. Comparison not needed.
By the way, those two Chinese characters in Ed's last post might look the same in some displays. They look the same in Fedora HYPERKITTY in my Firefox, and in my Thunderbird "Write" window, but different in my Thunderbird main message display. They look the same in my Gnome terminal.
I'm really having an off day. I sent the message below to the list with an attachment when that should have been sent off-list. The message to the list should have had a link as shown below.
On 2020-02-29 12:05, home user wrote:
On 2020-02-28 02:34 PM, Ed wrote:
So why are there two separate AR PL UKai fonts - the CN and the TW? What *is* the difference?
Well, that would require a comparison of the fonts. However, I do know that there are terms/characters used and created in Taiwan which are not used in the PRC. So, it is possible that the TW font contains them and the CN not. The reverse is also possibly true. FWIW, the same holds true for HK.
I had read that before, and since forgotten. What Ed said completely answers my two questions about the 2 AR PL UKai fonts. Comparison not needed.
By the way, those two Chinese characters in Ed's last post might look the same in some displays. They look the same in Fedora HYPERKITTY in my Firefox, and in my Thunderbird "Write" window, but different in my Thunderbird main message display. They look the same in my Gnome terminal.
Actually, thanks for telling me. I can now amend my answer. My assumptions were wrong.
See https://drive.google.com/file/d/1xTYVez2DRm7GKg6dguev1s49GFJKIGkl/view?usp=s...
The circled character on top is U+5167 and should be the Traditional rendering. The one below is U+5185 and should be the Simplified rendering.
So, now we know the real difference between the CN and TW AR PL UKai fonts.
The authors of the font have decided to render all characters in the style associated with either CN or TW depending to the selected font.
To me, that is a bad choice and another reason why I'd avoid that font.
On 2020-02-29 09:37 PM, Ed wrote:
So, now we know the real difference between the CN and TW AR PL UKai fonts.
Are you certain? The Chinese word for the musical percussion instrument that in English is called a "gong" is "luo" (2nd tone). In one of my notes files (a .txt file), the simplified and traditional forms of the character do differ. They also differ in this web page in my Firefox: "http://www.mandarintools.com/cgi-bin/wordlook.pl?word=%E9%94%A3&searchty..." See attachment terminal.png to see a screen capture of the relevant part of the vim session in a Gnome terminal. See attachment webpage.png to see a screen capture of the relevant part of the mandarintools.com webpage in my Firefox. I am seeing both versions of the character in the CN font.
On 2020-02-29 13:18, home user wrote:
On 2020-02-29 09:37 PM, Ed wrote:
So, now we know the real difference between the CN and TW AR PL UKai fonts.
Are you certain?
It seems only for certain characters they are indistinguishable.
楊 v.s 杨
Are OK in that font. So, maybe my original suggestion is more inline.
Anyway..... I think this has been exhausted. :-)
The only thing that matters is that all movie subtitles I download for my wife must be in TC.
When I use Chinese characters, I choose a font for 2 practical reasons...
1st: readability. Some simplified characters I've used consist of over 20 characters. Traditional Chinese characters, when different from simplified ones, usually consist of more strokes than their simplified equivalents. Of the currently in-use characters, I think the record is biang (2nd tone), which, depending on what constitutes one stroke, consists of 58 strokes (traditional Chinese) or 42 strokes (simplified Chinese). (See "https://en.wikipedia.org/wiki/Biangbiang_noodles" for more about the "biang" character.) For me, the regular (KaiTi) fonts seem to display "busy" characters better, more clearly, than do the Ming and sans-serif fonts.
2nd: experience. I have taken 3 vacations in China (all to mainland China). The rest of my experience with Chinese is with Chinese co-workers and friends. I'm not anything close to fluent in Chinese. Ed seems to have been in Taiwan for many years. So he has far more experience with Chinese, and so can probably handle more fonts better.
Then there's personal preference. I prefer orchestra music over solo musician/instrument music, old hymns over modern praise music, (for Roman characters) serif fonts over san-serif fonts, and the pipe organ over all other instruments. If you pick up on the pattern, you understand that I prefer regular (KaiTi) Chinese text over Ming and sans-serif Chinese text.
There are advantages and disadvantages with each font. I'm almost certain that any font will be missing many Chinese characters (I've read that there are over 50,000 Chinese characters, simplified-only + shared, or traditional-only + shared). Beyond that, I've only encountered two problems with the AR PL UKai fonts, the open double quote problem being one of them. (And it's not clear that it's a font problem: Firefox handles it correctly, Gnome terminal does not.) Weighing things, sticking with AR PL UKai fonts is what's best for me (and for some other people). Using Ming or san-serif fonts is what's best for other people.
The original questions were where to file a bug, and against what to file the bug. I'm now convinced that filing a bug is very unlikely to help. So I'm marking this thread "CLOSED". I thank everyone who invested time and effort to help. And we did learn along the way.
Bill.
On Sat, 2020-02-29 at 14:18 -0700, home user wrote:
Beyond that, I've only encountered two problems with the AR PL UKai fonts, the open double quote problem being one of them. (And it's not clear that it's a font problem: Firefox handles it correctly, Gnome terminal does not.)
One difference there, is that Firefox is happy dealing with proportional fonts, most terminals expect monospace fonts.
On Sat, 2020-02-29 at 8:54 PM, Tim wrote:
One difference there, is that Firefox is happy dealing with
proportional fonts, agreed.
most terminals expect monospace fonts.
As it is stated, I agree. The problem is what constitutes a "monospace" font.
I spent some time experimenting. I tried lines of Chinese text mixed with lines of English text. I did this in a Gnome terminal using a font plainly having "mono" in its name (FreeMono Regular), and in a Gnome terminal using an AR PL UKai font. In *both* cases, English characters always take up 1/2 the horizontal space used by Chinese characters.
Decades ago, Judy Collins sang that she really didn't know clouds, love, and live a-a-t all. It seems we (including myself) really don't know "monospace", fonts, and terminals much better!
-
Dave Stevens -
Ed Greshko -
home user -
Samuel Sieb -
Tim