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

Render curved quotes #176

Closed
xcoulon opened this issue Aug 25, 2018 · 7 comments
Closed

Render curved quotes #176

xcoulon opened this issue Aug 25, 2018 · 7 comments

Comments

@xcoulon
Copy link
Member

xcoulon commented Aug 25, 2018

See https://asciidoctor.org/docs/user-manual/#curved

@xcoulon xcoulon added this to the v0.1 milestone Oct 13, 2018
@xcoulon xcoulon modified the milestones: v0.1, v0.2 Oct 27, 2018
@xcoulon xcoulon modified the milestones: v0.2, backlog Feb 11, 2019
@shuLhan
Copy link
Contributor

shuLhan commented May 14, 2019

@xcoulon Can you give an example for this case? I have an issues that may or may not related to single/double quotes, to minimize duplicate issue which I want to report.

Thank you.

@xcoulon
Copy link
Member Author

xcoulon commented May 14, 2019

@shuLhan my case is that for text such as mother's day will be output as mother’s day.

See https://asciidoctor.org/docs/user-manual/#curved. I'll edit the issue title and description to clarify.

@xcoulon xcoulon changed the title Render opening/closing single and double quotes Render curved quotes May 14, 2019
@xcoulon
Copy link
Member Author

xcoulon commented May 14, 2019

@shuLhan don't hesitate to open a new issue if you found a bug ;)

@gdamore
Copy link
Collaborator

gdamore commented Jun 16, 2020

So it turns out that I need this too (I used this syntax extensively in my docs).

There are two dimensions of this problem.

First, we need to support "and" (and also 'and') elements. These are inline elements like a String Element. Notably asciidoctor does not process these "sanely" if they cross a paragraph (and presumably any block) boundary. This probably creates some challenges to their use. Which is unfortunate, because nobody really wants to type "&8217;."

Secondly, is the problem of automatically recognizing that a lone apostrophe should be curved when it appears without whitespace, along with the code to be smart about the use of "" to escape them.

The particular rules also need to be savvy about code blocks, which creates some real challenges. TBH, I believe that there can be ambiguity in the mark up language.

I'm not entirely sure how best to solve this. The need is pressing for me, because I did use it heavily. I might just "fix" my documents to use replacements instead.

I've got a solution which I think mostly does the right thing for apostrophes like mother's day, but a general solution to the explicit typographic entities is likely to be harder.

@gdamore
Copy link
Collaborator

gdamore commented Jun 16, 2020

Actually in this day and age, we have unicode. I know this is mean to be "ASCIIDOC", but really, there is no reason we can't inject UTF-8 explicit characters into place. That's what I would recommend folks do for now.

@gdamore
Copy link
Collaborator

gdamore commented Jun 18, 2020

See also #620. I am considering this bug to just be the handling of mother's day style markup, with a renderer time substitution (for now -- although we might want to do this at parse time in the future).

@gdamore
Copy link
Collaborator

gdamore commented Jun 25, 2020

So there are two cases to cover here.

  1. mother's day (apostrophe with letters on both sides)
  2. mothers`' day (typographic curved apostrophe)

It would be most natural to render these typographically using unicode on the backend, and then replace the unicode with an escaper for the asciidoctor compatible HTML. (Other backends should not use those escapes, and frankly are better off not doing so -- even in asciidoctor the epub backend leaves unicode unmolested.)

@gdamore gdamore self-assigned this Jun 26, 2020
@gdamore gdamore modified the milestones: backlog, v0.5.0 Jun 26, 2020
gdamore added a commit to gdamore/libasciidoc that referenced this issue Jun 26, 2020
This provides support for both explicit typographical quotes, and
the implicit curved apostrophe when it appears between letters
as in mother's day.

This also refactors the handling of certain typographic symbols,
moving their handing from the render to the parser, so that they
are treated properly during the parse phase.  (This was important
in properly handling these curved quotes.)

Also, the greedy rules for string elements in quoted text were
removed, as they were interfering with the parse, and not strictly
required.  (They were an optimization.)  It's our opinion that for
most documents quoted text will be in the minority, such that
the performance gain provided by the old rules was minimal at best.

Fixes bytesparadise#176
gdamore added a commit to gdamore/libasciidoc that referenced this issue Jun 26, 2020
This provides support for both explicit typographical quotes, and
the implicit curved apostrophe when it appears between letters
as in mother's day.

This also refactors the handling of certain typographic symbols,
moving their handing from the render to the parser, so that they
are treated properly during the parse phase.  (This was important
in properly handling these curved quotes.)

Also, the greedy rules for string elements in quoted text were
removed, as they were interfering with the parse, and not strictly
required.  (They were an optimization.)  It's our opinion that for
most documents quoted text will be in the minority, such that
the performance gain provided by the old rules was minimal at best.

Fixes bytesparadise#176
gdamore added a commit to gdamore/libasciidoc that referenced this issue Jun 26, 2020
This provides support for both explicit typographical quotes, and
the implicit curved apostrophe when it appears between letters
as in mother's day.

This also refactors the handling of certain typographic symbols,
moving their handing from the render to the parser, so that they
are treated properly during the parse phase.  (This was important
in properly handling these curved quotes.)

Also, the greedy rules for string elements in quoted text were
removed, as they were interfering with the parse, and not strictly
required.  (They were an optimization.)  It's our opinion that for
most documents quoted text will be in the minority, such that
the performance gain provided by the old rules was minimal at best.

Fixes bytesparadise#176
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants