Minecraft Version

1.16.5

Forge Version

36.2.23

Mantle Version

1.6.152

Tinkers' Construct Version

3.3.2.324

Describe your issue

In reviewing #4707, I found text overflow in Puny Smelting, p38, in Japanese.
This situation will be caused, not only in Japanese, when multiple columns are misaligned by long text that it breaks lines.

Forcing people to revise their translations is not very kind.
I think you should review the column layout.

Crash Report

No response

Reproduced with only Tinkers' Construct?

Yes

Other mods required

No response

Confirm the following

• Confirm you have checked the roadmap, what's new, and the FAQ for your issue
• Confirm you have searched the tracker to see if your issue already exists
• Confirm you are not using performance enhancers, such as optifine

I was aware of this problem, but I recognize that cleaning up the display of the book is not a currently priority thing.
This can be improved somewhat by using a smaller font with a resource pack.

Not all TiC players install font mod/resourcepack in their installation. And I think that font mod/resourcepack is not only for resolve this problem, it provide players to use fonts what their favorite or readable,
Also, this problem will limits font variety of players' selection in font mod/resourcepack. In other words it will make that the fonts players to use the most will be hard to use due to this issue.
And I don't think it's a desirable situation at all to leave players in a situation where the presence of a problem forces them to install these things.

The issue has to do with how the book calculates columns. It has logic in place to prevent the case described by this bug, though its pretty finicky. In any case, its really a Mantle bug, as that is where the book library comes from. Mind posting there?

As a workaround for the Japanese translation, you can override the title for a particular page to make it shorter. I do it in the english version of the book, shortening Unarmed Attack to Unarmed (might be in the encyclopedia). I can give you more info if you want to try that workaround.

No, it does not affect all languages. If the language does not set upgrades.diamond, it gets the default. I was just lazy and did not set names on all of them. Test with the english page to verify.

All pages have a name, setting name just means it has a sensible one instead of autogenerated like upgrades.page47

In other words, set the name in the section, it will not break anything.

It worked. But not good. Japanese is good but English is broken(replaced by Japanese words).

Actually, should the language.json has all modifier entries in en_us, even if the same in English? Because other language may substitute it.

This one?

I added "upgrades.diamond" section in language.lang of "Puny Smelting", but not worked.
Is this only encyclopedia?

It's done.

However, it seems that I need to update the file in "sections" folder to make this happen. This file is not language-specific, but common to all languages, so I can't seem to fix it.

You have to give the page a name in the section. If it has no name, you cannot use the trick. You will notice in the sections, unarmed is the one with a name

I'm aware.
"abilities.json" in "sections" directory has the following description.

I found that I could fix as above by adding a name section to the diamond in sections/upgrades.json of Puny Smelting, and adding upgrades.diamond=ダイヤ to language.json. However, this fix should not be acceptable for solving the issue because changing the file of "sections" directory affects all languages.

Depending on the language, the length of the translated word will vary. For example, in Japanese, "unarmed" is not too long, so this trick is unnecessary. The best thing would be to change it so that the substitution can be done in a file in the directory for each language. Is this a Mantle task?

Sorry. This was a bit inaccurate. If I set the language to Japanese first, and then change it to English, it will look like the above. If I started Minecraft in English, it was displayed in English. If this is the case, do I not need to worry about it?

I apologise that the Japanese translator is kindly reviewing them translation, but this issue is overflow of page content that can occur when many sentences are used that are too long to be broken lines.
Therefore, no matter how changing translation, the issue itselft will nod be fixed in the end because it's only a workaround.

@KnightMiner In the beginning I thought to request you to transfer this issue into Mantle's. But currently, should I repost same issue itself to the Mantle repository? Since there is now an exchange of information on workarounds that bypasses this issue.

Thank you for fixing the issue of keeping undesirable cache. By using trick, I will add a fix to PR that resolve the issue with broken lists. I will leave the handling of this issue to the author and developer.

I apologise that the Japanese translator is kindly reviewing them translation, but this issue is overflow of page content that can occur when many sentences are used that are too long to be broken lines.
Therefore, no matter how changing translation, the issue itselft will nod be fixed in the end because it's only a workaround.

Yes, I am aware the workaround does not fix the issue. That is why I requested reporting the issue to Mantle so it can be properly tracked and fixed in the future.

Fixed in Mantle 1.9.50 for 1.18. I'll keep this issue in mind as a potential issue for backport to 1.16 though.

Fixed in 3.7.0.152 for 1.18.2. I have labeled this for backport so if I do another 1.16.5 build, it will be addressed.

I recognized that resolved means this issue is resolved on whole this mod lifecycle.
In other words TiC has already terminated of update for minecraft 1.16 if my thought is correct.

1.16 is unlikey to receive another release at this point, though I'll consider it before the 1.19 port

After quite a bit of debugging, I managed to find the cause of this issue and fix it. The logic I had in place that was meant to deal with this issue by calculating the number of lines a "too long" line of text would take was running on the string including the bullet point, which often caused it to split the text at the space between the bullet point and the word. For long words containing no spaces, this caused a discrepancy between the Mantle text rendering logic that never splits there, and the estimated split length which considers a split there. I have updated the logic in Mantle to correct for this, so the next Mantle version should fix this. Will leave a comment when its updated.

Is it for 1.18? The original issue was for 1.16.