clbarnes / asciidoc-named-char-refs Goto Github PK

Hi, I followed your comment from asciidoctor/asciidoctor-pdf#969

I too struggle to see why the PDF output cannot handle XHTML and HTML5 character entities. If it does for HTML output it is confounding that it does not for PDF. The XML argument against it is dubious as argued by the many commentators in the thread; especially the obvious one, i.e., that "pound" is a lot easier to read than "#163" and asciidoc touts its readability.

After some hair pulling, I found this seems to be an alternative solution:

In asciidoctor.rb under INTRINSIC_ATTRIBUTES you can add all of the entities you like, e.g.:

    'iexcl' => '¡',
    'cent' => '¢',
    'pound' => '£',
    'curren' => '¤',

I have put the entire XHTML set in there and PDF output was mostly fine (the font inadequacies aside). The only thing that failed was case insensitivity, so Agrave and agrave both rendered as the lowercase version. I did not really understand that because, although I know almost nothing about Ruby, I read that its hashes are case sensitive, which I tested interactively...that was confusing. However, just changing the one line in substitutors.rb from elsif doc_attrs.key?(key = $2.downcase) to elsif doc_attrs.key?(key = $2) resolves that (without any obvious side effects that I have seen so far anyway).

The net result is that {iexcl}, {cent}, {Agrave} and {agrave}, etc., work for both HTML and PDF outputs (the only two I tried).

Example output showing these in the last column
examplePage.pdf

And an example line from the input .asciidoc file:
|\Ù |Ù |\Ù |Ù |U+000D9 |latin capital letter U with grave|{Ugrave}¶

Currently, enclosing underscores leads to more characters for names which use capitals for distinguishing words (e.g. CapitalDifferentialD -> _C_apital_D_ifferential_D_), and require escaping when the first and last letters are both capitalised.

The alternative would be to prepend an underscore to any letter which should be capitalised, which may not require escaping, requires fewer keypresses for the example above, but feels less asciidoc-y, and is worse for names like ETH (_ETH_ vs _E_T_H).

Lastly, might including the convenient lower-case alternative (e.g. capitaldifferentiald) possibly threaten forwards-compatibility, if W3C eventually release a new spec where those all-lower names mean some other unicode character?