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

Fix rendering of allowed characters. #60

Merged

Conversation

Carreau
Copy link
Contributor

@Carreau Carreau commented Apr 26, 2020

The default rule for sphinx with simple backticks seem to be "cite",
which is rendered in italic, making it relatively hard to distinguish
what is the set of characters meant vs, formatting.

On my initial read on current page I actually though the trailing dot
was finishing the sentence, and it was not clear whether or not spaces
(and or commas) were part of allowed character.

With the double quote each character group is rendered: monospace, and in
a different color (for current theme)


Sidenote, I see no mention of encoding in this section, I'm guessing this character set has been chosen to be "safe" in the sens ascii-compatible right ? In which case you might want to actually specify the bytes range maybe as not all encoding will get these as the same bytes:

In [1]: from string import ascii_letters, digits
In [2]: (ascii_letters + digits).encode().decode('utf16')
Out[2]: '扡摣晥桧橩汫湭灯牱瑳癵硷穹䉁䑃䙅䡇䩉䱋乍偏剑呓噕塗婙\u3130㌲㔴㜶㤸'

The default rule for sphinx with simple backticks seem to be "cite",
which is rendered in italic, making it relatively hard to distinguish
what is the set of characters meant vs, formatting.

On my initial read on current page I actually though the trailing dot
was finishing the sentence, and it was not clear wether or not spaces
(and or commas) were part of allowed character.

With the double quote each character group is rendered: monospace, and in
a different color (for current theme)
@joshmoore
Copy link
Member

Thanks, @Carreau. Recently ran into the same issue myself. Merging proactively, and I'll paste a screenshot from readthedocs.org as a post hoc review.

@joshmoore joshmoore merged commit da684fe into zarr-developers:core-protocol-v3.0-dev Apr 27, 2020
@joshmoore
Copy link
Member

joshmoore commented Apr 27, 2020

@alimanfoo
Copy link
Member

Many thanks @Carreau.

Sidenote, I see no mention of encoding in this section, I'm guessing this character set has been chosen to be "safe" in the sens ascii-compatible right ? In which case you might want to actually specify the bytes range maybe as not all encoding will get these as the same bytes

This is something that needs some clarification. I think encoding is an issue for the store implementation, i.e., the core protocol does not need to specify an encoding, just a set of characters that are allowed. But that needs explanation.

(Also I think the set of allowed characters should be expanded, xref #56.)

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 this pull request may close these issues.

3 participants