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

[simple-ruby] Leave room for manual overrides #14

Closed
bert-github opened this issue Apr 2, 2020 · 9 comments · Fixed by w3c/jlreq#204
Closed

[simple-ruby] Leave room for manual overrides #14

bert-github opened this issue Apr 2, 2020 · 9 comments · Fixed by w3c/jlreq#204

Comments

@bert-github
Copy link

The rules aim to give a reasonable placement in all cases, but, as the introduction mentions, people have used other placements to solve specific problems. One would hope that a system that implements the simple placement rules still allows a typographer to do things differently. Maybe the text should say that somewhere. It currently only says that explicitly for the font size of the ruby, which need not be 1/2.

@frivoal
Copy link

frivoal commented Apr 3, 2020

If this were a normative specification, it would be important to be clear about what is a should and what is a must, and where the extension points are.

However, it is not that kind of document, and I think it is better to focus on simply describing the method as it is. In any real system, there will be much more complication brought by interaction with other features (or other languages), as well as a desire for further nobs and levers to tweak things, but that's out of scope here, and would complicate the body of the text.

However, if this is just about adding a sentence to the introduction, without complicating the main text, then why not. For instance, we could add towards the end of 1.2

The following is a proposal for a simple processing system. The target audience is implementers and specification writers. It is expected that a full system may be more complex that what is described here, both due to the interaction with other features or other writing systems, and because those designing such system may wish to provide additional options.

@r12a
Copy link
Contributor

r12a commented Apr 3, 2020

Iiuc, during the i18n telecon, Bert was also concerned that authors should be able to not follow these rules in certain circumstances, eg. to do katatsuki for certain ruby items rather than nakatsuki. Maybe that would be covered by changing 'additional' in the last sentence above to 'alternative'?

frivoal referenced this issue in frivoal/jlreq Apr 3, 2020
This leaves room for future extensions, manual overrides, and other
tweaks, while letting the document focus on the simple system without
getting into all sorts of corner cases and side discussions.

Closes #200
frivoal referenced this issue in w3c/jlreq Apr 3, 2020
This leaves room for future extensions, manual overrides, and other
tweaks, while letting the document focus on the simple system without
getting into all sorts of corner cases and side discussions.

Closes #200
@r12a r12a transferred this issue from w3c/jlreq Apr 3, 2020
@murata2makoto
Copy link

There are many possible design choices, and Kobayashi-sensei chose one of them. Consensus-based technical changes will simply make the document less useful, I think.

@r12a
Copy link
Contributor

r12a commented Apr 4, 2020

What specific technical changes are you concerned about? I don't think any such changes were made to the document.

@murata2makoto
Copy link

What specific technical changes are you concerned about?

Allowing manual intervention. Adding katatsuki. Mentioning possible customization. Everything beyond tiny editorial changes.

@frivoal
Copy link

frivoal commented Apr 4, 2020

Consensus-based technical changes will simply make the document less useful, I think.

I agree. The body of the text should stay unchanged other than tiny editorial changes. The edit I made to close this issue was to make a short mention in the introduction that an actual system based on "simple ruby" might customize things. This this is not a normative specification, people can do whatever they want anyway, so to me saying it in the introduction is a way of not repeating it everywhere, which would make things more complicated and dilute professor Kobayashi's approach.

@r12a
Copy link
Contributor

r12a commented Apr 6, 2020

I don't believe that the aim of this document was or is to ban all alternatives to what is described, and mandate the model described here as the maximum limit of what can be done with ruby. (I also don't think that would be practical or appropriate.) My understanding is that the document was intended to simply describe one minimal level of support for ruby.

The recent edits have not changed the model from what it was. The new paragraph in the introduction is merely an acknowledgement that some implementations may go farther that what is described here – it doesn't extend or change the model described here.

Here is the relevant part of that new paragraph:

The following is a proposal for a simple processing system. The target audience is implementers and specification writers. It is expected that a full system may be more complex that what is described here, both due to the interaction with other features or other writing systems, and because those designing such system may wish to provide alternative options

@murata2makoto if you disagree, please quote the actual text you have a problem with so that we can pinpoint the topic(s) for discussion. (Note btw, that the latest version of the document is now at https://w3c.github.io/simple-ruby/).

@r12a r12a reopened this Apr 6, 2020
@murata2makoto
Copy link

@r12a Your paragraph looks fine to me.

@r12a
Copy link
Contributor

r12a commented Jun 8, 2020

Ok, thanks. Closing this then. (That para is still in the latest version.)

@r12a r12a closed this as completed Jun 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants