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

Entire CJK stack upside down #1245

Open
alerque opened this issue Sep 21, 2021 · 8 comments
Open

Entire CJK stack upside down #1245

alerque opened this issue Sep 21, 2021 · 8 comments
Assignees
Labels
bug Software bug issue
Milestone

Comments

@alerque
Copy link
Member

alerque commented Sep 21, 2021

I'm monkey-patching some stuff through to get the manual to build for v0.12.0, but the entire Japanese language support and Tate / Ruby package scene is chaos. I'm adding fallback fonts early everywhere so the units and things work if called from anything other than an already working environment, but the order is all wrong. You can't measure glyphs before you load fonts, which means you can't measure glyphs in class init.

@alerque alerque added the bug Software bug issue label Sep 21, 2021
@alerque alerque added this to the v0.12.x milestone Sep 21, 2021
@alerque
Copy link
Member Author

alerque commented Sep 21, 2021

Basically see everything in #1215 except the first commit.

@ctrlcctrlv
Copy link
Member

I totally agree with you. I have a better version of the Ruby package which I will be PR'ing soon…it's just a matter of finding a charger, fixing an old laptop etc. Maybe I'll get to it now. But yes, really tate.lua/ruby.lua is not so good but I find myself quite outnumbered in terms of caring about doing anything as I seem to be the only user. Furthermore, I only am interested in Japanese typesetting (so the J in CJK) making me an unsuitable general expert.

@alerque alerque modified the milestones: v0.12.1, v0.12.x Jan 12, 2022
@alerque alerque modified the milestones: v0.12.3, v0.12.x Mar 2, 2022
@alerque alerque removed this from the v0.12.x milestone Apr 18, 2022
ctrlcctrlv added a commit to ctrlcctrlv/sile that referenced this issue Jun 18, 2022
ctrlcctrlv added a commit to ctrlcctrlv/sile that referenced this issue Jun 18, 2022
@Omikhleia
Copy link
Member

Omikhleia commented Jun 23, 2022

I don't know if it fits here in this issue, but there seems to be some code smell in the tate/break-firstfit/ja logic.

I am illiterate as far as Japanese is concerned, and have know idea what a "hangable" thing means in this language, but anyhow I can't see how the isHangable would ever be valued. It doesn't seem we have some logic for it (as opposed, say, to the is_box etc. constructs, which are valued via the node's type at construction).

My apologies if the above assumption is wrong -- It's just something I saw by accident and which left me perplexed.

@ctrlcctrlv
Copy link
Member

@Omikhleia It should not be removed. The "hangable" there refers to characters that may be in the ぶら下げ組 (burasage-gumi; lit. (maybe) overhanging class (of characters)) of jlreq §2.5.1.c, which states:

ぶら下げ組とよばれる処理をした場合は,行頭禁則の処理を必要とする句点類(cl-06)及び読点類(cl-07)に限り,行末の版面の領域の外側に接して配置する(Figure 38).なお,ぶら下げ組についてはJIS X 4051に規定されていないが,同規格の解説8.1)c)に説明がある.

Line adjustment by hanging punctuation is only necessary for full stops (cl-06) and commas (cl-07) when they would otherwise need to be wrapped to the line head. The character is placed so that it touches the hanmen at the line end (see Figure 38). (Hanging punctuation is not defined in JIS X 4051, but there is an explanation in sec. 8.1, c.)

Cf. https://www.w3.org/TR/jlreq/#id83

image

It should be fixed. isHangable and hangable are identical entities. This being broken is highly unsurprising given the sad state of tate (although it's better than nothing which is what most software that attempts to compete with LaTeX provides).

@ctrlcctrlv
Copy link
Member

Btw I suggest moving a lot of languages/ja.lua into a new file to be called packages/jlreq.lua. There are reasons you'd want some jlreq algorithms for non-Japanese. @alerque ?

@alerque
Copy link
Member Author

alerque commented Jun 24, 2022

Yes, any tooling that is generic for a family of genre of languages could be abstracted to module files that can be require()ed into whatever specific languages they are needed. Eventually I'll probably make the language support modules actually classes so they have an official inheritance model to follow so we can deal with region codes etc., but that isn't off the ground yet. For now my only comment on the proliferation of Lua files is that all files to be loaded with require() should return modules or functions rather than doing anything directly. They can have stuff in their local scope if desired but loading them should not touch anything in the global scope until explicitly called. We have a lot of code that wasn't written that way and it's costing me a lot of time to fix along the way.

@ctrlcctrlv
Copy link
Member

@simoncozens seems to be on leave from SILE but I would really like his comment on the patch I put on the other issue (#501 (comment)) against ctrlcctrlv/sile@14b7547.

@alerque
Copy link
Member Author

alerque commented Jul 8, 2022

So, um, GitHub is very bad at surfacing notifications for some things. @ctrlcctrlv I was just mucking around looking for how to set an away message since I'm going to be mostly off the computer for a few days, and I spotted something on my profile I missed for more than a month. More on that later when I'm back I suppose, I just wanted to at least start with a duly deserved “dankon”!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Software bug issue
Projects
Status: No status
Development

No branches or pull requests

3 participants