Re: smallcaps: Re: Experimental public branch for inline special blocks
Max Nikulin writes:
> OK, just consider it as my dissenting opinion. I believe that it should
> be possible for the same Org document
>
>#+options: inline-special-block-aliases:(("definition" :smallcaps t))
>
>{Example} or &_[:smallcaps t]{ad-hoc}
>
> to export it as
>
>Example
>or ad-hoc
>
> or as
>
>Example
>or ad-hoc
>
> by adjusting of global settings. The former one be suitable for a CMS
> that does not allow user CSS and the latter one is preferable for a site
> under full user control and having CSS
>
>.definition, .small-capps { font-variant: small-caps; }
With the current implementation this:
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
{Example}
produces:
Example
:smallcaps simply adds a (say) direct formatting layer. I am not a fan
of any form of direct formatting. But, as I already said, I think that
these types of global attributes can be useful for users who do not want
to bother with predefining styles, classes or commands in
odt/html/LaTeX, or because they do not know how to do it. They simply
want a text to be exported with a certain color or with small caps, or
with more effects (in case more global attributes are implemented
(background color, text size, etc).
I think an option could be added to disable global attributes or specify
which backend they should be used on. Anyway, I would not see it
necessary, but perhaps other users think differently.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
Re: smallcaps: Re: Experimental public branch for inline special blocks
On 06/03/2024 00:28, Juan Manuel Macías wrote:
Max Nikulin escribió:
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.
OK, just consider it as my dissenting opinion. I believe that it should
be possible for the same Org document
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
{Example} or &_[:smallcaps t]{ad-hoc}
to export it as
Example
or ad-hoc
or as
Example
or ad-hoc
by adjusting of global settings. The former one be suitable for a CMS
that does not allow user CSS and the latter one is preferable for a site
under full user control and having CSS
.definition, .small-capps { font-variant: small-caps; }
Re: smallcaps: Re: Experimental public branch for inline special blocks
Max Nikulin escribió:
> If some type is used through the document multiple times then it is
> better to avoid style="font-variant:small-caps" and use a CSS class
> instead. Even for LaTeX it may be better to define a dedicated command
> to be closer to semantic markup.
>
> Moreover different decorations may be used in LaTeX and HTML. Some type
> may be typed in small caps in LaTeX, but in HTML it may use regular font
> and some color.
The "global attribute" concept implies that there should be (ideally)
the same result in all possible backends (naturally, if the output is
plain text, :color doesn't make much sense). Global attributes are a
quick and easy (for the user) way to create direct formatting, analogous
to the LaTeX commands \textcolor, \textsc, etc. Its casual use is the
most recommended, in my opinion. Let's imagine that a user wants to
color segments of text, in the same color, for LaTeX and odt, and does
not want to bother with predefined styles or macros in odt and LaTeX
respectively.
If a segment of text must have a different appearance, for example, in
LaTeX (small caps) and HTML (red color), you can put:
&_[:html style="color:red;" :prelatex \scshape{}]{text}
And if one wants to have more robust control, for example because many
text segments must have a certain treatment in HTML, odt or LaTeX,
styles, classes and macros can always be defined in the output format.
Additionally, there are the :odt-style, :latex-command, :html-tag and
:html-class attributes to override what is necessary. What's more, in
specific cases global attributes can be added.
I think that the current implementation is very flexible and gives rise
to many possible variations, and the combination of direct formatting
and styles to suit the user.
--
Juan Manuel Macías -- Composición tipográfica, tratamiento de datos, diseño
editorial y ortotipografía
smallcaps: Re: Experimental public branch for inline special blocks
On 02/03/2024 03:34, Juan Manuel Macías wrote:
│ Caesar's famous quote: ![:smallcaps t :color blue]{Alea iacta est}
==> LaTeX:
│ Caesar's famous quote:
{\scshape{}\color{blue}\foreignlanguage{latin}{\textit{Alea iacta est}}}
== HTML:
│ Caesar's famous quote: Alea iacta est
I am in doubts if smallcaps should be hardcoded. From my point of view,
current implementation is unnecessary rigid. In this particular example
:smallcaps is an ad-hoc property. I would expect its usage through an
alias definition, e.g.
#+options: inline-special-block-aliases:(("definition" :smallcaps t))
If some type is used through the document multiple times then it is
better to avoid style="font-variant:small-caps" and use a CSS class
instead. Even for LaTeX it may be better to define a dedicated command
to be closer to semantic markup.
Moreover different decorations may be used in LaTeX and HTML. Some type
may be typed in small caps in LaTeX, but in HTML it may use regular font
and some color.
Perhaps an e.g. user-configurable and extensible alist of types with
per-backend properties should be used instead.
A portion of wisdom how to represent small caps for each export backend
may be handy, but accessing it should be more flexible.
