uvtc commented 11 years ago

Now that Pandoc supports line blocks, here's some syntax that might work nicely for left/center/right -justifying lines:

Hi.

| left-justified
| preserves leading space
| last line

|< also left-justified
|< does not preserve leading space
|< last line

|> right-justified
|> another line
|> last line

|<> centered
|<> another line
|<> last line

Bye.

Thoughts?

uvtc commented 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

uvtc commented 11 years ago

Reasons why I like this syntax:

consistent with how Pandoc already marks blocks in general (such as blockquote and indented code blocks: by using a prefix on each line)
nicely fits in with and extends how Pandoc now marks lineblocks
consistent with how line blocks are handled (all line block forms would not wrap lines)
shouldn't break any existing docs, since line blocks were only just added
looks like what it does, looks good, easy to remember
syntax is unlikely appear accidentally where not intended

uvtc commented 11 years ago

by ignoring leading spaces, allows writers to make centered and right-aligned lines look in source format what they will look like in the output format

ghost commented 8 years ago

Background

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:

Story Title
Author byline
Word count
Scene separators (i.e., # or * * *)
Story ending (i.e., THE END)

Additionally, screenplay cover pages are entirely centered.

Markdown should standardize text justification (left, right, center) before competing, and perhaps conflicting, syntaxes flourish.

Precedent

Centered text exists in various Markdown flavours:

And is actively employed by various web sites:

Syntax

This section describes several syntax mechanisms for text justification.

Justified Pipes

This justified pipe syntax builds on Pandoc's existing block syntax.

|<> Centered
|< Left-justified
|> Right-justified

Mirrored Arrows

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.

Mirrored Angle Brackets

A simpler syntax to the mirrored arrows is used by screenplay writing software:

> Centered <
>: Left Justified <
> Right Justified :<

Arrow Block

A single token to denote centering:

-> Centered

Double-colon Prefix Block

A regular block of text is centered using a prefix:

center::
Centered

Ini-style Prefix Block

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.

Cat Whiskers

A single token to denote centering:

>< Centered

Attribute Block

Use CSS-style attributes:

==== {.center #center_demo}
Centered
====

Arguments Against

This section describes the arguments against including a centered Markdown syntax.

Non-Descriptive

| 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.

Feature Complete

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.

Slippery Slope

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.

Arguments For

This section describes the arguments for including a centered Markdown syntax.

Precedent

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.

Competing Syntax

Developing a standard in Markdown itself should help prevent competing standards from emerging.

Historic Typography

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.

Single Source

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.

Professionalism

Professionally typeset manuscripts and screenplays require certain aspects to be centered.

Usage Barrier

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.

Microsoft's Stranglehold

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.

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.

tgy commented 7 years ago

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!

ousia commented 7 years ago

@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.

v1kn commented 7 years ago

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.

ickc commented 7 years ago

Probably this should be tagged "AST Change".

v1kn commented 7 years ago

@ickc It's quite a while since the issue was opened. Do You reckon there's possibility the Devs will work on it?

ickc commented 7 years ago

@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.

v1kn commented 7 years ago

@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.

jgm commented 7 years ago

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.

ghost commented 7 years ago

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.

ickc commented 7 years ago

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:

dedicated centering element (how about right justified then?)
A Div with class to indicate it is centering
Overload the LineBlock element, and let it carries attributes to indicate if it is left-justified (the old LineBlock), centered, or right-justified.

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.

ghost commented 7 years ago

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;
}

ickc commented 7 years ago

@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.

ghost commented 7 years ago

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.

jgm commented 7 years ago

+++ 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.

ghost commented 7 years ago

; --- {.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.

bpj commented 6 years ago

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.

sjackman commented 5 years ago

A workaround is to use a table with no header and a single centred column.

|     |
|:---:|
| This
| text
| is
| centered


This
text
is
centered

igormcoelho commented 5 years ago

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?

ghost commented 5 years ago

@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

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.

igormcoelho commented 5 years ago

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 :)

sjackman commented 5 years ago

$$maximize \sum_{i \in X} p_{i}$$ is centered in PDF output, but not in HTML output.

igormcoelho commented 5 years ago

$$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).

sjackman commented 5 years ago

Have you tried using pandoc -Fpandoc-crossref?

$$ math $$ {#eq:label}

See http://lierdakil.github.io/pandoc-crossref/#equation-labels

igormcoelho commented 5 years ago

@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!

sjackman commented 5 years ago

I'm glad to hear that it helped!

uvtc commented 5 years ago

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:

easily recognizable/readable,
visually distinct from an HR,
doesn't require any new syntax markers (and actually uses some that were previously locked up and unavailable for mardown syntax since they were exclusively used for HR's),
shouldn't render badly on impl's that don't support it, and
pretty well looks like what it means.

What do you think?

jgm commented 5 years ago

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.

sjackman commented 5 years ago

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.

uvtc commented 5 years ago

@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 flexible (you may use more than 3 marker characters if you like, and you get to pick the marker character --- just like with HR's)
the characters are just all the same single character but repeated (no complicated character combos)

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.

mb21 commented 5 years ago

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.

ghost commented 5 years ago

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?

joshhansen commented 5 years ago

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:

if trailing=0 and leading > 1: align right
if leading > 0 and trailing > 0 and leading approximately equals trailing: align center
otherwise align left

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....

alerque commented 5 years ago

@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.)

joshhansen commented 5 years ago

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.

ftomassetti commented 4 years ago

Is this still being considered?

blaggacao commented 4 years ago

CenTerD>TEXT  [WRITE TEXT HERE]

Jokes aside:

------       centered text

------       THE END OF #719

alpianon commented 3 years ago

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!
:::

fbertoia commented 2 years ago

Hello to all, No update for centering text ? 😭

bpj commented 2 years ago

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.

mdengler commented 1 year ago

This would definitely be nice to have

jgm / pandoc

request: syntax for centering text #719

Background

Precedent

Syntax

Justified Pipes

Mirrored Arrows

Mirrored Angle Brackets

Arrow Block

Double-colon Prefix Block

Ini-style Prefix Block

Cat Whiskers

Attribute Block

Arguments Against

Non-Descriptive

Feature Complete

Slippery Slope

Arguments For

Precedent

Competing Syntax

Historic Typography

Single Source

Professionalism

Usage Barrier

Microsoft's Stranglehold

Related