{U+1147, U+1167} (whether followed by U+302E or not} is not combined into a syllable in the vertical writing mode. {{{ ᅇᅧ〮 ᅇᅧ }}}

Vertical: the last (leftmost) two lines have the sequences in question:

Horizontal: the last (bottommost) two lines have the sequences in question:

Will check other syllables starting with U+1147. This is checked with Chrome 55.0.2883.87. I'll also check with HarfBuzz 1.4.2.

@kenlunde

안녕하세요? Noto Serif CJK에 대한 문자(조합용 한글 자모) 추가를 제안하렵니다.

아시다싶이 북한에서는 1948년에 "조선어 신 철자법"을 제정되며 그 안에 새로 , , (자음-첫소리 및 끝소리), (모음-가운뎃소리)의 4가지 자모가 사용된 바 있습니다.

해당 자모들은 북한 사회에서 널리 사용되지는 못하였으나 북한의 논문(조선어 연구)나 문법서(조선어 문법)등에서 일정한 정도 사용됐습니다. 특히 "조선어 문법"은 북한의 국어문법 연구사를 알아볼 때 꼭 필요한 자료 중 하나일 것입니다. 이러한 자료들을 전산화하려면 해당한 자모를 입력할 수 있어야 한다고 생각을 합니다. 그래서 PUA든 Hangul Jamo Extended-B(이건 별도의 절차가 필요하겠으나)든 위 4개 자모들을 추가해 주시면 고맙게 생각합니다.

감사합니다.

en자료: https://en.wikipedia.org/wiki/New_Korean_Orthography https://commons.wikimedia.org/wiki/Category:DPRK_New_Korean_Orthography_(1948-1954) (참고) https://commons.wikimedia.org/wiki/File:Proposal_to_add_the_%E2%80%9C6_letters%E2%80%9D_(Hangul_Jamo).pdf

ko자료: https://upload.wikimedia.org/wikipedia/commons/f/fe/조선어신철자법.pdf https://ko.wikisource.org/wiki/%EC%A1%B0%EC%84%A0%EC%96%B4_%EC%8B%A0_%EC%B2%A0%EC%9E%90%EB%B2%95 https://ko.wikipedia.org/wiki/%EC%A1%B0%EC%84%A0%EC%96%B4_%EC%8B%A0%EC%B2%A0%EC%9E%90%EB%B2%95

ja자료: https://ja.wikipedia.org/wiki/%E6%9C%9D%E9%AE%AE%E8%AA%9E%E6%96%B0%E7%B6%B4%E5%AD%97%E6%B3%95 https://ja.wikisource.org/wiki/%E6%9C%9D%E9%AE%AE%E8%AA%9E%E6%96%B0%E7%B6%B4%E5%AD%97%E6%B3%95

As reported at this Ubuntu bug, the NotoSansCJK.ttc bundle does not work well with the Google Chrome and Chromium web browsers. Those browsers pick "Thin" as the default font weight.

The issue is not present if you install the 36 individual OTF files or the 7 weight specific OTC files instead of NotoSansCJK.ttc.

Copied from googlei18n/noto-fonts#718 filed by @c933103

See https://ja.wikipedia.org/wiki/三式潜航輸送艇 , in noto font, the character cannot enclose a hiragana character into it as would have been expected. (The combination: ゆ⃝ )

The "Kanbun" sinographic marks (U+3190...U+319F) are rendered the same as plain CJK characters.

They should be rendered as superscript (centered in the top help for the first one, "tateten", or occuying the top-left quarter of the ideographic box for the 15 other "kaereten"), instead of remapping the standard CJK (which should then be rescaled to 50% to 60% of width or height, and repositioned, with slightly simplified stroke to improve readability).

But it seems that you have just remapped the same glyph betweeen the full-square ideographs, and the Kanbun marks.

Note: these are NOT "compatibility" characters but really they are annotation marks. Rendering them as standard characters just creates ambiguity/confusion.

This affects ALL existing CJK fonts families (Noto Sans CJK, Noto Serif CJK), in the four supported language groups (JP, KR, TC, SC), and all styles and weights.

For reference, look at this chart: https://www.unicode.org/charts/PDF/U3190.pdf

Noto sans CJK Japanese, Adobe acrobat DC, PDF creator, cube pdf, Promo pdf and a few Japan local pdf softwares(Free and commercial). Windows7 32bit, 64 bit

making PDF via pdf printer driver, almost only 2 bit character text are deleted (a few character is kept) Using other font, no delete.

1. Printer setting -> postscript option-> output option -> change "EPS" We can print only Page 1.
2. Printer setting -> postscript option-> output option -> change "Archive" Lost header information.

Changing from Noto sans to Han sans font (adobe), we have no-trouble Adobe acrobat PDF maker have no-trouble with Noto sans CJK japanese.

Probably, Noto sans CJK Japanese do NOT support postscript print with postscript PDF printer driver. Or Noto sans CJK Japanese have a bug for postscript PDF driver..

fonts: all serif and sans software MS word 2016

example docx file: sample_docx.docx pdf file export from sample_docx.docx by MS word: sample_pdf.pdf

No fonts has been embed.

U+339F, U+33A3, U+33A4 look bad. See the image below:

339F ㎟ SQUARE MM SQUARED ≈ 006D m 006D m 00B2 ² 33A3 ㎣ SQUARE MM CUBED ≈ 006D m 006D m 00B3 ³ 33A4 ㎤ SQUARE CM CUBED ≈ 0063 c 006D m 00B3 ³

BTW, this was filed internally : b/21499141

Same as https://github.com/googlei18n/noto-fonts/issues/1128.

I also wrote somethings about the reason why KDE Konsole and other Qt application does not consider Noto Sans Mono (CJK) monospace fonts in https://github.com/googlei18n/noto-fonts/issues/1128#issuecomment-379988287.

Discovered in Sans. U+881B in zh-Hans and zh-Hant has 示 instead of 衣 on the LHS. According to the Unicode code charts, in all locales, LHS should be 衣.

In order to have monospaced serif for Latin characters (Courier replacement) mixed with embedded CJK characters for program listings (e.g., out of DocBook)

Environment: archlinux+texlive2022 Compile: Tried both xelatex and lualatex MWE:

\documentclass[fontset=none]{ctexart}
\setCJKmainfont{Noto Sans CJK SC}[RawFeature=+fwid]

\begin{document}
a \symbol{"2E3A} a
\end{document}

You can change Noto Sans CJK SC to Noto Sans CJK SC Bold or Noto Sans CJK SC Light, and it turns out that the thickness of the dash \symbol{"2E3A} has barely changed

Bold:

Light:

As long as [RawFeature=+fwid] is turned on, it will be like this, whether you use —— or \symbol{"2E3A}, you can compare it with when [RawFeature=+fwid] is not turned on, the thickness of the Chinese dash is obviously different from that of em dash in Western which follows the thickness growth.

This will cause the dashes to appear very thin when in regular/medium/bold/black, which doesn't match the text very well

These are supported in some UI fonts like HarmonyOS Sans

Equal-Width and Variable-Width Digital Fonts

In text mixing, the default proportional figures are used, which improves reading coherence in text paragraph reading. Tabular figures are used in scenarios where the values need to be emphasized and data needs to be frequently changed in tables and clock digits. This ensures the alignment of digit width and a better graphical display.

Clock Font Features

The colon format is automatically adjusted to the center based on the time format.

In Sans/Variable/TTF/Subset/NotoSansJP-VF.ttf (and possibly other fonts), a large number of glyphs are present in the subsetted fonts but do not seem to be reachable through encoding or any substitution rules. They appear to be language-specific variant forms which were not subsetted out. Some examples are:

• glyph01660
• glyph01663
• glyph01665
• glyph01667
• glyph01668
• glyph01673
• glyph01677
• glyph01682

(There are over 800 in total.)

OS: Arch Linux DE: KDE Plasma Display Protocol: X11

When font is set to "Noto Sans", some specific CJK characters (including 一, 夏, etc.) are not rendered correctly (see this screenshot). This happens in both GTK and Qt applications.

The last known version of noto fonts that does not have this problem is 20201226, so this issue could have been around for a while.

If I use language specific google font css api, the font-face is generated with unicode-range.

How about Noto Sans CJK? What is the unicode-range?

And also whether Noto Sans CJK includes cyrillic-ext, cyrillic, devanagari, greek-ext, greek, vietnamese, latin-ext, latin ?

I want to use Noto Sans CJK to replace the mutliple CSS rules generated by google font css api.

https://fonts.googleapis.com/css2?family=Noto+Sans:[email protected];400;500;600;700&family=Noto+Sans+HK:[email protected];400;500;600;700&family=Noto+Sans+TC:[email protected];400;500;600;700&family=Noto+Sans+SC:[email protected];400;500;600;700&family=Noto+Sans+JP:[email protected];400;500;600;700&family=Noto+Sans+KR:[email protected];400;500;600;700&display=swap