Open uvtc opened 11 years ago
Better:
| left-justified
| preserves leading space
| last line
|< also left-justified
|< ignores any leading space
|< last line
|> right-justified
|> ignores leading space
|> last line
|<> centered
|<> also ignores leading space
|<> last line
Reasons why I like this syntax:
Intermixing HTML tags (or TeX macros) with Markdown to center objects (text, images, tables) is a format-dependent solution to the centering text problem. It should be possible to write a single source file in Markdown and generate all formats that publishers require and Pandoc can export, without resorting to format-specific markup. The publishing industry, academics, technical writers, poets, and bloggers use centering extensively. To wit, centered text alignment dates back 500 years, if not earlier.
Centering is not an arbitrary formatting feature, but integral to professionally typeset manuscripts. Elements centered in a proper manuscript format include:
#
or * * *
)THE END
)Additionally, screenplay cover pages are entirely centered.
Markdown should standardize text justification (left, right, center) before competing, and perhaps conflicting, syntaxes flourish.
Centered text exists in various Markdown flavours:
And is actively employed by various web sites:
This section describes several syntax mechanisms for text justification.
This justified pipe syntax builds on Pandoc's existing block syntax.
|<> Centered
|< Left-justified
|> Right-justified
The table colon syntax can be applied to enhance the arrows with left/right justification:
-> Centered <-
->: Left Justified <-
-> Right Justified :<-
This is compatible with countless existing documents that already use centering.
A simpler syntax to the mirrored arrows is used by screenplay writing software:
> Centered <
>: Left Justified <
> Right Justified :<
A single token to denote centering:
-> Centered
A regular block of text is centered using a prefix:
center::
Centered
A combination of Windows .ini
file syntax and block environments:
[center]
| A paragraph that needs to be centered
| This is similar to blockquote, but with `|` as the
| starting character rather than `>`. The name of the block
| is at the beginning of the block.
This could be extended:
[align:center]
| This block is centered.
[align:left]
| This block is left-justified.
[align:right]
| This block is right-justified.
A single token to denote centering:
>< Centered
Use CSS-style attributes:
==== {.center #center_demo}
Centered
====
This section describes the arguments against including a centered Markdown syntax.
| Centering is a presentational instruction, and Markdown should separate semantics from presentation
This is the strongest argument against its inclusion, but still falls a bit short. Consider:
| Tables | Are | Cool |
|----------|:-------------:|------:|
| col 1 is | left-aligned | $1600 |
| col 2 is | centered | $12 |
| col 3 is | right-aligned | $1 |
The Markdown strongly suggests the content is tabularized data and should be presented as such. How the table looks (cell padding, spacing, background colours, bold headers, borders, etc.) is definitely outside the scope of Markdown. However, everyone who types up such ASCII tables is aware that a single comma-delimited paragraph will not be generated (illegible to humans and impossible to machine read, generically). Some tables can be presented in other forms, such as pie charts, but those are likely exceptions.
On a similar token, _ ... _
suggests underscores, / ... /
strongly suggests italics, and ** ... **
often ends up bold, all of which are indisputably presentation. Additionally, #
suggests a header, but how it finally appears is presentation (e.g., font size, face, weight, and colour; page breaks; underlines; numbering; and, yes, alignment).
No semantic meaning is attached to / ... /
and ** ... **
; whereas, #
and ##
are meaningful, semantically. Therefore we cannot argue against including centered text because it lacks semantic meaning. Semantic meanings are inapplicable to centering because it applies to many unrelated text fragments: story titles, author names, pen names, publisher names, by lines, copyright notices, warnings, poetry, word counts, endings, etc.
To say that Markdown completely separates content from presentation is slightly disingenuous because source code blocks and monospaced fonts are practically inseparable.
Adding a hint to center text can be considered a separation of content from presentation. Text marked down as centered doesn't have to be presented as centered any more than a code block must be presented in a monospace font or _ ... _
must be rendered using underscores. Centered text could be presented as a marquee, blinking (please no), underlined, embossed, offset in a box, or any number of ways that are applicable to text marked with ** ... **
; it could even be centered on the page, which, like tables being rendered as tables, would be the most likely outcome.
Markdown, by its very nature, can never be feature complete.
By this reasoning, lambda expressions should not be added to existing programming languages. Nobody has proposed hard limits on what Markdown is meant to accomplish. Markdown has a stated purpose: to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid X/HTML. Yet, as Pandoc has shown, Markdown can also be a simple, human-readable, filetype-agnostic structured text format.
Agree that centering is useful, but completely disagree that it belongs in Markdown. It's a slippery slope once you open the door to any formatting features. This is why Markdown allows HTML tags.
First, the slippery slope is a logical fallacy. Second, mixing HTML tags and Markdown eliminates the possibility of a single, pure Markdown source to automatically generate a wide variety of output formats.
This section describes the arguments for including a centered Markdown syntax.
A number of precedents currently exist in the wild for a centering syntax. While this is argumentum ad populum, it certainly speaks to a practical need in the real world.
Developing a standard in Markdown itself should help prevent competing standards from emerging.
Centering has been in use since before the printing press. Although this falls under argumentum ad antiquitatem, again, it speaks to the practical need to center text.
There is no way to write a single, pure Markdown file and generate centered text in a wide variety of output formats (from XHTML to ConTeXt) to meet various industry needs. Intermingling format-specific tags or macros defeats the purpose of a single source.
Professionally typeset manuscripts and screenplays require certain aspects to be centered.
Most people aren't programmers; there are people who don't have the capacity or desire to even learn how to mark up text. (This is why Microsoft Word and other such WYSIWYG word processing software is so popular and widely used.) Forcing people to embed fragments of indescribably foreign code to do something as simple as center (or justify) text builds a high barrier to using Markdown.
Currently, Microsoft Word dominates manuscript submission requirements (Analog, Lightspeed, Mothership, Fantasy Scroll, Flash Fiction, New Accelerator, Tor, Asimov, and many others strongly prefer or outright demand .doc or .docx manuscript submission formats). This will not change until a viable, simpler standard is created.
Most of the content in this comment is a summary of the following threads:
I would also have noted that the formatting, not semantic, super- and sub-scripting exist already in pandoc and in various markdown flavors.
People will want to write their centered text in the center, like this:
-> some centered text <-
|<> some centered text
rather than
-> some centered text <-
|<> some centered text
because it just looks better that way.
But with the mirrored arrows syntax, how can you tell if it's meant to be centered text or verbatim text?
Another aspect of |<>
I like is that since that marker is placed at column 0, it's easier to see if I've entered two or one newlines after (or before) typing in the centered text content (presuming I'm writing it centered in the page, as described above).
People will want to write their centered text in the center, like this:
I prefer the |<>
syntax to the mirrored arrows, so long as the following produce equivalent results:
|<>Centered Text
|<> Centered Text
|<> Centered Text
| How can you tell if [mirrored arrows are] meant to be centered text or verbatim text?
Good point. Also, some text editors might confuse <-
with HTML comments (<!--
), thus making a mess of syntax highlighting.
What are the next steps? Vote for what syntax to use, get agreement from the core developers, develop a prototype integration, or something else?
People like doing complex formatting, where markdown cannot
People like doing complex formatting
What "people"? That presupposes a certain type of people who want to use Markdown. Name them. Here are classes of people whose writing or industry could benefit from the simplicity of Markdown formatting:
Here are classes of people whose work sometimes requires complex formatting, which makes Markdown unsuitable:
where markdown cannot
Nobody has drawn a line in the sand that states, "Markdown shall not do this." Markdown has no scope. Rather, subjective terms like "simple" and "human readable" attempt to reign in its extents. This will cause endless debate whenever additions are proposed.
The former planet Pluto was considered a planet until the word planet was given a formal definition. Markdown suffers in the same way: it lacks formal definition. That "Markdown cannot do this" doesn't mean "Markdown shall not do this."
Also... You say, "It can't." I say, "It can." That's not a debate with any technical merit or hints of rational thought: it's a pointless religious debate that cannot be resolved in any meaningful way.
What are the next steps? Vote for what syntax to use, ... {snip}
There's no voting, per se. From what I've seen, feature requests may be left open for a while to give folks time to mull them over, discuss, and possibly create patches. Of course, it's easy to add features but difficult to remove them (once folks are using them). Also, some requested features would be extremely useful, but might make the pandoc-markdown format too noisy, or clash with some other existing usage, or break backcompat, or not work with all (enough?) output formats.
Nobody has drawn a line in the sand that states, "Markdown shall not do this." Markdown has no scope.
IMO, pandoc-markdown balances somewhere between capturing common usage (what you'd normally/naturally write in a plain text email or an online comment), and providing enough features to help you get away from Word/LaTeX/HTML. While looking good doing it. ;) A difficult task.
What is the current status for this? Markdown centering is something I would really like to see.
It is very important for scientific content when you want to center figures for example!
@tgy, as far as I remember, images accept attributes, so you can use attributes to center images.
I think it is way more important (and more useful) that paragraphs accept attributes than they may be aligned.
I just found this issue, while looking for solutions to my problems. @DaveJarvis Thank You for a thorough essay on the rationale. I hope this feature will get implemented at some stage.
Probably this should be tagged "AST Change".
@ickc It's quite a while since the issue was opened. Do You reckon there's possibility the Devs will work on it?
@v1kn,
I'm not the core-developers, so I can't tell. That said, I guess the priority will be low, considering that any "AST Change" level of issues are complicated and there are already many of them (in addition to the complexity involved, I would guess that a lot of thought would be given before any AST Change is made to get it right the first time). Just to illustrate the level of complexity: all reader/writer pairs for each format is needed to be updated, and depending on exactly what is involved, the tools built around pandoc needed to be updated too: pandoc-templates, pandoc-citeproc, any "filter framework" that parses the pandoc AST into its own, e.g. panflute, etc.
However, we can bend it such that it doesn't require an AST Change. e.g. just use a Div with class "center":
Cons:
uglier, generic syntax (but Div might soon receive a markdown syntax, see #168, which also means even if we settled for a Div syntax for now, potentially in the future a markdown-ish syntax suggested above could be implemented in the future.)
such a class is generic enough that existing documents might have already used it, so that such change might accidentally break someone else' documents when they update pandoc.
Pros:
no AST Change, much easier to implement, and from the history of similar commits, it can be started with some common, easier to implement output formats first (e.g. LaTeX and HTML related outputs). i.e. not all formats has to be implemented at the same time.
If one accept this route of using Div with class rather than a tailored syntax, then such feature can be implemented through a filter, completely bypass pandoc. It means you can start doing so right now, rather than waiting on a long discussion and approval process. Note that the filter as a proof of concept too, so it doesn't eliminate the possibility of pandoc supporting it natively.
@ickc Thank You for a detailed explanation. Yes I can see now this is no easy task with fast solution.
I will try some workarounds using templates for the time being, but I will be sure to keep an eye on both this and #168 issue.
We might implement this at some point, but I'd advise using filters for now. There are other AST changes, like colspans in tables, that are higher priority.
If issue #168 is resolved, then this issue can be closed, as an additional syntax for centering would be superfluous:
; --- div {.centered}
; Lorem ipsum dolor sit amet, consectetur adipiscing
; elit, sed do eiusmod tempor incididunt ut labore et
; dolore magna aliqua. Ut enim ad minim veniam.
If issue #168 is resolved, then this issue can be closed, as an additional syntax for centering would be superfluous
Not necessarily. It depends if one accepted the suggestion of using generic Div and a class to centering, or want a dedicated syntax for centering, similar to LineBlock (the original suggestions make comparison to LineBlock, and consider centering/LineBlock to be special cases of justifications).
In terms of AST, while one could imagine LineBlock syntax can be parsed as a Div with a certain class, but pandoc actually assigned a special element to it, which by the way cannot carries attributes at the moment. So to solve the centering problem in terms of AST, one can tries at least these methods:
So when I suggest using a Div, it is the 2nd approach. But the 3rd approach could as well be a viable option, especially if the syntax of centering will be similar to LineBlock's.
So there're 2 related considerations:
philosophically, does one want to generalize LineBlock to include centering/right-justification? (i.e. how one categories it.)
syntactically, does one want to have a dedicated syntax for centering/right-justification? And if so, does one want to make them similar to LineBlocks?
If the answers are no to both, then using Div with classes is the simplest solution, and is a solution that can happens right now.
Lastly, I have a related question: what if one want to center/right-justified other kind of elements, say Headings? If this is desirable, then using a class can immediately generalize it to any pandoc elements that can carries attributes, while overloading LineBlock will limit it to just LineBlock-like texts.
if one accepted the suggestion of using generic Div and a class to centering
Yes, this is the reason I included an example block, to show the syntax that would obviate this feature request:
; --- div {.centered}
...
what if one want to center/right-justified other kind of elements, say Headings
Headings and other elements can be styled without a specific class attribute because they can be uniquely referenced. This applies equally to HTML and TeX code. It's even possible to style the same heading level in different ways:
# First Heading
Paragraph
# Second Heading
Paragraph
Using CSS3, center every second heading as follows:
h1:nth-of-type(2) {
text-align: center;
}
@DaveJarvis,
; --- div {.centered}
...
compared to @uvtc's for example,
|<> centered
|<> also ignores leading space
|<> last line
The latter is definitely better fitting the philosophy:
A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
I remembered @jgm mentioned somewhere (probably in CommonMark when commenting on Microsoft's another attempt on a tool similar to pandoc/MultiMarkdown) that using English words to describe what it is is worse than using a syntax to show it (e.g. non-English documents). While we are talking about a class here (not just some syntax using English word), when someone read it as a plain-text, it is the same to them. i.e. all they read is just an English word.
Just to make it clear, I am not opposing to either approaches (that's why I suggested using a Div instead earlier). But I'm just pointing out the others might have other considerations. So we need to wait if they have any other opinions before closing it.
And even if one settled to use classes for centering, should one do it with Div, or LineBlock (LineBlock cannot carries attributes right now, but it seems that it will eventually be supported)? That's the "philosophical" part I mentioned above.
LineBlock cannot carries attributes right now, but it seems that it will eventually be supported?
I understand, thank you for clarifying.
Readability, however, is emphasized above all else. A Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.
That is an issue. Perhaps @uvtc, @jgm, or @jgruber might want to chime in with their thoughts on this potential divergence from Markdown philosophy.
+++ ickc [Jan 07 17 12:26 ]:
I remembered @jgm mentioned somewhere (probably in CommonMark when commenting on Microsoft's another attempt on a tool similar to pandoc/MultiMarkdown) that using English words to describe what it is is worse than using a syntax to show it (e.g. non-English documents). While we are talking about a class here (not just some syntax using English word), when someone read it as a plain-text, it is the same to them. i.e. all they read is just an English word.
My main objection to the use of English words is that not everyone writes in English.
One nice thing about Markdown as opposed to, say, LaTeX, is that if you're writing in (say) Swedish, your document isn't littered with English words. It's ALL in Swedish, with some punctuation. People have sometimes commented on how nice this is.
; --- {.poesi}
...
; --- {.poem}
...
How the "poem" is presented (centered, right-justified, etc.) is independent of the Markdown. Any language can denote that the paragraph is a stanza. That is to say, no formatting instructions are present, though {.poem}
could be considered a tag, which would go against the philosophy.
I came across this when looking for line block related issues to check if another issue I have had been reported. I have not read everything here (it's a lot!) but I thought that now when we have a nice div syntax what about making a class like .center
(and perhaps also .centre
to prevent problems due to human errors) on a div magical, so that writers output the right format dependent markup around it if possible?
In LaTeX that would presumably be the center
environment, or a minipage
with centering
at the top (see here for the difference!)
I think that in HTML it should perhaps be up to the user to implement/link the necessary CSS based on the class rather than polluting the default template with more in-document CSS. Remember that it's hard or impossible to override in-document CSS, whether in the header or in a style
attribute! The usually wanted CSS .center { text-align: center; }
could be mentioned in the documentation of the feature.
A workaround is to use a table with no header and a single centred column.
| |
|:---:|
| This
| text
| is
| centered
This |
text |
is |
centered |
Any updates on this? (how to center text on LaTeX via pandoc)
I wonder if these fenced_divs can be used somehow: https://github.com/jgm/pandoc/issues/4037 Something like:
::: center
test
:::
Or pehaps this pandoc-latex-environment, to somehow convert a div class "center" to the \begin{center} ... on LaTeX: https://github.com/chdemko/pandoc-latex-environment/wiki
---
pandoc-latex-environment:
center: [classcenter]
---
<div class="classcenter">content</div>
in LaTeX ->
\begin{center}
content
\end{center}
Sorry, I don't know much of the internals of pandoc (yet), and couldn't make any of them work... can someone give a clue on the latest advances here?
@igormcoelho, you can create a simple Lua script to convert custom blocks to centred text. Here's an example that creates a custom inline image based on a fenced div:
local lines_to_blocks = {
Image = function( el )
return {
pandoc.RawInline( "tex", "\\inlineexternalfigure[" .. el.src .. "]" )
}
end
}
function Div( el )
local kls, _ = el.classes:find_if(
function ( c )
return string.match( c, "^image%-" )
end
)
if kls then
return pandoc.walk_block( el, lines_to_blocks )
end
end
See also @jgm's https://github.com/jgm/pandoc/issues/2106#issuecomment-371508848.
Save the file as centre.lua
then call pandoc using:
pandoc --lua-filter=centre.lua
This then parses the following block:
::: image-inline
![](../climate/graph)
:::
To produce:
\inlineexternalfigure[../climate/graph]
Feel free to use this example to produce centred LaTeX code. Note that RawInline
may have to be changed to RawBlock
.
Thanks @DaveJarvis for the fast and detailed response. I can try to adapt this code, but my need involves centering an equation block on LaTeX, not an image... My block is specifically:
(@obj) $maximize \sum_{i \in X} p_{i}$
In fact, I could use \begin{equation} ... here, I would be centered in LaTeX, but totally unreadable for markdown, and I want to do that in a way that is compatible with markdown too, because we have both users editing the document.
Anyway, I'll try to change your script to RawBlock
and learn a little bit of lua :)
$$maximize \sum_{i \in X} p_{i}$$
is centered in PDF output, but not in HTML output.
$$maximize \sum{i \in X} p{i}$$ is centered in PDF output, but not in HTML output.
I see that, problem is that I'm using (@obj) to create a label that will be further cited:
(@obj) $maximize \sum_{i \in X} p_{i}$
On Eq. (@obj) bla bla bla...
I think that double $$ environment in LaTeX do not allow labels... And anyway, I have other parts of the text that I also need to centralize, this was just an example, so I've looking for a general way to do that on pandoc (since it's already possible on pandoc html by using div + css syntax).
Have you tried using pandoc -Fpandoc-crossref
?
$$ math $$ {#eq:label}
See http://lierdakil.github.io/pandoc-crossref/#equation-labels
@sjackman thanks a lot for this advice, besides solving my equation centralization issue, pandoc-crossref improved a lot the general readability of the text (removed all my \ref{bla} to a much more friendly @ref). Thanks!
I'm glad to hear that it helped!
If my suggestion (here, above, from 2013!) to build upon line block syntax is not desirable (possibly because adding a three-character |<>
side-mark syntax looks a lot like markup, and also may be going down a slippery slope of new multi-character syntax elements), consider the following:
Any centered syntax should look like what it means. It should look good and not too much like markup.
Centering text is actually pretty commonly needed, so the syntax for it should ideally be fairly succinct. In general, markdown avoids big multi-character markers anyway.
Markdown provides numerous ways to create a horizontal rule (HR). It's not that common to need an HR, but when you need one, there's a lot of ways to get one, and markdown doesn't care which one you use. This actually uses up some characters we might've preferred to use for something else, but here we are.
Typically, HR's are drawn centered.
The essence of an HR is that it's a divider; a delineation and a marker. Centered text is also a delineation and a marker of sorts.
I don't think we can re-use the fenced div syntax,
::: centered text!
because that looks like the start of a fenced div block. And anyway, markdown tends to use different markers for fenced syntax vs side-marked syntax for a given feature (for example, code blocks are prepended with spaces, but fenced with tildes or backticks).
An enclosing syntax could maybe work, but we're low on matching bracket characters, and so it would have to be some compound syntax, for example:
[- some centered text? -]
but that looks too much like markup, and I doubt people want to go down that road of a slew of future compound marker proposals like that. And anyhow, that enclosing syntax is associated with inline markup, not block markup.
And, of course, you've got to have some marker on the far left-hand-side, even for centered text, otherwise it'll be mistaken for an indented code block. But the marker on the left-hand-side isn't so bad, because it helps you see which line the centered text is on.
Give all that, how about this simple rule: if you follow a horizontal rule marker with spaces followed by text, then the text gets centered and the horizontal rule itself is omitted.
--- here is some centered text
That would be for single-line centered text only, though I suppose could also support a "lazy-style" (multi-line) variant.
Note: it's not a typical side-marked syntax (like blockquote, which encourages multiple lines, and which often uses a vertically-oriented character marker), but rather it's an extension of the existing HR syntax.
Does that cause ambiguities with any other pandoc-markdown syntax? I think it's pretty clear it's not an HR. Does it break anything? The only possible issue that comes to my mind is that ---
usually gives me an em-dash.
_ _ _ \* \* \*
So, this is a simple solution that's:
What do you think?
John Gabriele notifications@github.com writes:
Does that cause ambiguities with any other pandoc-markdown syntax? I think it's pretty clear it's not an HR. Does it break anything? The only possible issue that comes to my mind is that
---
usually gives me an em-dash.
Well, in addition,
* * * * hi
currently gives you a nested list in pandoc and most other markdown implementations.
Perhaps some variation of the table syntax that renders a paragraph rather than a table.
|:---:|
A paragraph of centered text goes here.
|----:|
A paragraph of right-aligned text goes here.
@jgm Ah, right. Thanks for pointing that out. I see there's the same issue with - - -
as well.
It's difficult to come up with light, sensible, obvious markup for centered text, which also degrades gracefully (for implementations that don't support it) and at the same time looks "classic" such that it will be readily adopted (begins being used not only because it's handy but because it just "looks right").
I think the difficulty is partly because most folks would, in an email, probably just write their "centered text" indented with spaces and be done with it.
some centered text
@sjackman , an issue with re-using table syntax is that, aside from possible ambiguity with table syntax, you are also then back to using multi-character markers (|:--
and so on), which could turn into an asciibet soup of new markers to remember. (I like |<>
, |>
, |<
because they kinda generalize line block syntax, but I understand that consistency isn't everything; brevity, simplicity, and good looks probably beat consistency here.)
Remember that the primary table syntax in pandoc-markdown is so simple that you may not even realize you're using it. :) The other table syntaxes (like |:--|
) are provided to give you more specialized formatting options, and/or are more easily generated by computer, but they're less "markdownish" and look more like markup.
Updated tightened-up suggestion: If a horizontal rule marker of the kind containing no interspersed spaces is followed by text, then the text is centered and the HR marker itself is omitted.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
-------- some centered text
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
******** some centered text
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
________ some centered text
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad
minim veniam, quis nostrud exercitation ullamco laboris nisi ut
aliquip ex ea commodo consequat. Duis aute irure dolor in
reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla
pariatur. Excepteur sint occaecat cupidatat non proident, sunt in
culpa qui officia deserunt mollit anim id est laborum.
This is simple, looks good, and seems obvious that it's meant to indicate centered text. It feels markdownish:
it's possible to (in the future?) support a lazy variant
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
****** some centered text
with a second line
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do
eiusmod tempor incididunt ut labore et dolore magna aliqua.
And I think, due to the similarities between between HR's and centered text, it works pretty well.
Centering is a presentational instruction, and Markdown should separate semantics from presentation
I tend to agree with this. That's why I'm not so sure we need new syntax. Following the precedent of smallcaps, underline and columns, I would be fine with using native div and span syntax and use something like the following:
::: centered :::
my text
:::
Currently, you need to write a filter to handle this, but this could potentially be handled by pandoc itself, if we decide it's common enough.
The following mixes content with presentation:
::: centered :::
my text
:::
As does:
::: centered small
Copyright notice
:::
Consider, instead:
::: footer
Copyright notice
:::
That is, rather than using the word "centered" to denote centered text, perhaps emphasis can be placed on separating content from presentation? Why does the text need to be centered? Is it a quotation? An indicator that a line of reasoning has stopped? A stanza from a poem? A header? A call-out? A warning?
Couldn't this be achieved using a heuristic instead of adding new syntax? Here's one approach:
For each line in a line block, we determine alignment based on the number of leading space characters, and the implied number of trailing space characters.
Leading spaces are the number of spaces between the pipe and the first non-space character (if any).
Implied trailing space characters are equal to the max line length in the block minus the position of a given line's last non-space character.
For example, consider this line block:
|left1
| left2
| centered
| right
In this block, the max line length is 13 ("right"). For each line in this block, we have the following number of leading and implied trailing spaces:
left1: leading=0, trailing=7
left2: leading=1, trailing=6
centered: leading=2, trailing=2
right: leading=7, trailing=0
For each line, the alignment is determined as follows:
This would give each line in the line block the expected alignment, using only the most natural of formatting. The main tricky bit seems to be defining "approximately equal" for determining if there are roughly the same number of leading and trailing spaces.
It would admittedly be a bit painful to manually align your text to the right, but it would also be what you'd have to do to get a nice-looking right-alignment in plain text. Perhaps editor macros/plugins could help with the task?
Thoughts? I'm not a Markdown expert so I'd guess I'm missing something obvious....
@joshhansen I'm sorry, but I think that particular suggestion fails on two counts:
Markdown traditionally tries to ignore quantities of space as much as possible. The existing variants to this (such as the 1–4 space indents to keep content connected to list items) are already problematic across implementations. This is likely to lead to both confusion and incompatibility.
The line-block syntax in particular is special in that it typically preserves leading spaces. This is often used for poetry markup. E.g.:
| Once a line
| indent me.
| Twice over
| me too.
...will convert to LaTeX as follows:
Once a line!\\
\hspace*{0.333em}\hspace*{0.333em}\hspace*{0.333em}\hspace*{0.333em}indent me.!\\
Twice over!\\
\hspace*{0.333em}\hspace*{0.333em}\hspace*{0.333em}\hspace*{0.333em}me too.
This behavior just happens to be critical to the book publishing I do using Markdown as the canonical content source. Trying to change the existing behavior would screw me and a lot of other people up.
(Of course that isn't even to mention that line-blocks have other implications. What happens when you want a centered paragraph with wrapped lines? Overloading the current syntax would make this impossible.)
Good point. This could be addressed by only considering explicitly present trailing spaces rather than implied trailing spaces (implied by a line being shorter than the maximum line length in the block).
Consider this version (note the trailing spaces after "centered"):
|left1
| left2
| left___3
| centered
| right
The alignment rule then becomes:
function alignment(line_length, max_line_length, leading, trailing) {
if(line_length == max_line_length && leading > 1) {
if(trailing == 0) {
return "right";
else if(leading approximately equals trailing) {
return "center";
}
}
return "left";
}
I'm not sure what you mean by "a centered paragraph with wrapped lines". Can you please expound?
Of course, as with many other aspects of pandoc, this would probably only make sense as an extension that's off by default. You mentioned poetry---that's my current use case, and I would find an extension like this incredibly useful.
Is this still being considered?
CenTerD>TEXT [WRITE TEXT HERE]
Jokes aside:
------ centered text
------ THE END OF #719
Centering is a presentational instruction, and Markdown should separate semantics from presentation
I tend to agree with this. That's why I'm not so sure we need new syntax. Following the precedent of smallcaps, underline and columns, I would be fine with using native div and span syntax and use something like the following:
::: centered ::: my text :::
Currently, you need to write a filter to handle this, but this could potentially be handled by pandoc itself, if we decide it's common enough.
A simple filter could be this:
function Div(el)
local class = el["c"][1][2][1]
if class == "center" or class == "right" then
local align = class
el["c"][1][2] = {} -- remove class
el["c"][1][3] = {
{ "style", "text-align:"..align..";" }, { "custom-style", align }
}
--[[ add attributes both for html and for docx (you need to define "center"
and "right" custom styles in your reference docx file) ]]
return el
end
return nil
end
It works with conversion to both html and docx, but to make it work with docx you need to define "center" and "right" custom styles in your reference docx file.
If you start the text line with a \
, you can also render the alignment in your markdown text, if you wish:
::: right
\ this text is right-aligned
:::
::: center
\ centered!
:::
Hello to all, No update for centering text ? 😭
After all it is very simple to make
::: {.center}
Centered.
:::
work:
local center_for = {
latex = {
pre = pandoc.RawBlock('latex', '\\begin{center}'),
post = pandoc.RawBlock('latex', '\\end{center}'),
},
-- add more as needed...
}
function Div (div)
if div.classes:includes('center') then
if center_for[FORMAT] then
local rv = {}
if center_for[FORMAT].pre then
rv[#rv+1] = center_for[FORMAT].pre
end
rv[#rv+1] = div
if center_for[FORMAT].post then
rv[#rv+1] = center_for[FORMAT].post
end
return rv
end
end
return nil
end
Not even 25 lines, and then I even made it customizeable.
This would definitely be nice to have
Now that Pandoc supports line blocks, here's some syntax that might work nicely for left/center/right -justifying lines:
Thoughts?