Kerning problem with Noto Sans Mono CJK JP

English
#1

I am using LO 7.5.3.2 on Fedora 38.

My default font for Japanese texts is Noto Sans Mono CJK JP. While entering text the different kana are separated by some space. But when printing the same text to paper, there is no space between the kana (kerning = 0). Western fonts give no problems.

I can’t remember having seen this behavior in previous versions of LO.

  • Is it possible to adjust kerning for a specific font?
  • Is it possible to have different spacing for editing or printing?

Ben

I have attached an odt, a pdf and a photo from a print. The photo shows only the bottom lines.

KerningTest.odt (15.4 KB)
KerningTest.pdf (57.4 KB)

KerningTestPrint
KerningTestPrint955×274 210 KB

#2

Don’t know much of this problem, but to allow inspection by others, please provide a small writer-document, so we can check settings in the document.
.
Also try to generate and upload a PDF. Is the problem showing also in the PDF? If not please also add a scan or photo of the printout. (But then I would suspect the problem inside CUPS…)

#3

I guess you’re printing through CUPS. Which printer definition do you use? How is your printer connected: USB, Ethernet, serial, …? Have you tried accessing your printer with another descriptor (“driver”) than the specific one? For instance, I get better result on my very old LAN PostScript printer with generic or HP “drivers” (it is not an HP; I think the engine inside is of Canon origin) than with the no-longer maintained specific ppd.

#4

My Brother laser printer is (has always been) connected through Ethernet. The regular Brother drivers haven’t changed with the last upgrade from Fedora.

#5

According to the pdf, they appear to be either Type 1 or Type 3 fonts. Those are all pretty old/obsolete fonts so that is where the problem probably starts.

For me, LO substituted what looks like NSimSum and had what looked like correct spacing. I copied and pasted a couple of paragraphs and applied Noto Mono (installed by LO on my computer) and the spacing looked very close together so I set kerning to 2.0 and it looks like what you expected. But it is a True Type font

#6

@khaledhosny2 could it be related to some of your recent work?

#7

No, the same spacing is seen when printing documents that haven’t changed since the upgrade

#8

@BenEngbers which question are you answering? Note that I asked another person (a developer who works on fonts and glyph positioning recently).

#9

@mikekaganski
Sorry, I was commenting on your question to @khaledosny2. The problem is not only related to odt files that have recently been changed.

#10

Sigh, I asked if Khaled’s recent changes to the program code could cause it. Is it clearer now? The code that manages glyph positioning, no matter in new or existing documents.

#11

Sounds like 156151 – PRINTING: Chinese characters rendering overlaps when no printer configured

#12

Try printing to file, if the PDF file has the spacing issue and the exported PDF does not, then it is most likely the issue above and you can try one of the daily builds at the end of the bugzilla issue to confirm it.

#13

The PDF-files give no problem. The spacing problem arises only when printing to paper.
This problem was introduced after upgrading to Fedora 38.

#14

Did you create them using print to file or export to PDF?

#15

Export to PDF.
Printing to a PDF file is more laborious than exporting to PDF. Hence, I rarely if ever print from LO to a file.

#16

I’m trying to understand if your issue is the same as the issue I linked to in my first replay or not, and if print to file has the same spacing issue, then it is the same issue and you have to wait for the next update. If not, then it is a new issue that should be reported on bugzilla.

#17

Since I can only see the spacing problem when printing to a pinter, the problem can only be reproduced when a printer is installed. This means that it is different from your first reply.
When issuing a new bug, should I mention this trail or not?

#18

The presence of a configured printer is irrelevant, that detail of the bug report was a red-herring.

#20

Lol. It is almost literally a blast from the past:

If a programmer asks you for extra information, don’t make it up! Somebody reported a bug to me once, and I asked him to try a command that I knew wouldn’t work. The reason I asked him to try it was that I wanted to know which of two different error messages it would give. Knowing which error message came back would give a vital clue. But he didn’t actually try it - he just mailed me back and said “No, that won’t work”. It took me some time to persuade him to try it for real.

#21

As far as I understand it now, there are 2 different processes for creating a PDF; exporting to a file or printing to a file. And apparently the result of the second process is forwarded to the printer? That’s something I didn’t know.
Now that I do know that, I also understand the background of Khaled’s question. Had I known that earlier, I could have also given the correct answer earlier and thus avoided misunderstanding.
Lesson learned: never overestimate the knowledge of the other person and explain why a question is asked.

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.