For example:
[small]#some small text#
[big]#some big text#
in PDF appears as a regular sized text.
Adding
base:
font_size_large: $base_font_size * 1.5
font_size_small: $base_font_size * 0.75
to theme description did not help
PR #350 addresses this issue. I do not know what is stopping it from being merged.
There are some things in the PR I like, others I don't. I think it's going to need to be split up into smaller chunks. I just haven't had a chance to get to it yet.
Specifically, I don't want to support any built-in behavior. The role should be mapped back to settings in the theme to give it meaning. This encourages proper semantics. The big and small were something we implemented in core to be compliant with AsciiDoc Python, but I think these built-in names are a very bad idea.
In other words, the focus is adding support for custom roles that you define yourself in the theme. We won't support any roles for colors or named sizes out of the box.
I imagine something like:
stress:
font_size: $base_font_size * 1.5
And
[stress]#key word#
I'm still thinking about the best way to categorize these roles in the theme (should they be put inside a category?)
custom roles sound great! But supporting big and small are necessary in my opinion, to be compliant with asciidoc
If you want to define big and small roles in your theme, you absolutely can do that.
Ok, for me. But just a suggestion to pre-define them and allow overriding, I think it will help to avoid confusion in many cases when people read asciidoc manual and surprise why big and small do not work with asciidoctor-pdf
While we're still debating how to handle generic roles in #368, a case can be made that the big and small roles are central enough to the semantics of AsciiDoc to support out of the box. In addition to working in the HTML converter, there's already a concept of large and small base font sizes in Asciidoctor PDF, as pointed out in the description of this issue. So the big and small roles can simply be wired to these keys.
In order to support big and small in any context, the relative size (e.g., em value) should be computed from the concrete base values in the theme and used.
Most helpful comment
Ok, for me. But just a suggestion to pre-define them and allow overriding, I think it will help to avoid confusion in many cases when people read asciidoc manual and surprise why big and small do not work with asciidoctor-pdf