Use with Raku and PDF generation

[tbrowder]

I would love to use podlite in my Raku code, especially for producing certain relatively simple PDF documents. From looking at it over the years it looks like Raku's "pod" and podlite share a lot in allowable syntax and utility.

Some questions:

1. Given Raku's foray into a superset of the original pod6, is there a current list of incompatible features between the three versions?

2. Given podlite's PDF generation capability, can it provide any of the following:

   • text horizontal align: center, right, justified
   • text vertical align: underline, strikethrough, overbar
   • page break
   • page numbering
   • font selection

If not, are there any plans to add any of the above?

[zag]

Hey 👋 thanks a lot for your message and for following Podlite’s progress!

Given Raku's foray into a superset of the original pod6, is there a current list of incompatible features between the three versions?

You’re right — Podlite started as a lighter version of the original S26, and it keeps growing while staying true to the same core ideas.The main difference is that Podlite is not tied to any specific programming language, which makes it much more flexible and widely usable.

While building the Raku knowledge base, I went through around 7,000 files (*.pod6, *.rakudoc, *.rakumod, *.p6, *.markdown), and there were no critical issues. That was a good sign that Podlite’s spec works well with other dialects.

Given Podlite's PDF generation capability, can it provide any of the following:
text horizontal align: center, right, justified
text vertical align: underline, strikethrough, overbar
page break
page numbering
font selection

Yes — page breaks are already planned and will be available through the =pagebreak block.

As for the others, Podlite still follows its original principle:

Podlite is a purely descriptive markup notation, with no presentational components.

This approach keeps the markup simple and focused on structure rather than appearance — but it also makes it easier to render in different formats later.

For your use case (creating lightweight PDFs from Raku), the template-based approach will probably be the most exciting.
It works like CSS in web development — you’ll be able to define how each block or section should look in a PDF.
Templates can target elements by their block name or :id, giving full control over layout and style without mixing presentation into the document itself.

Thanks again for your thoughtful questions — I really appreciate it ❤️

[tbrowder]

Thanks. That sounds great, and I think the template approach is the way to go. I'll look around some more.

Any idea when the =pagebreak will be available?

[zag]

Thanks! 😊 glad to hear the template approach sounds like a good fit.

About the =pagebreak block — there’s no exact release date yet.
right now there’s a bit of a gap between the spec and the implementation, since some parts still need to be tested and verified in practice.
I’m planning to go through the spec review and updates once things settle down after the winter holidays — so most likely sometime early next year.
thank you

[zag]

👋 @tbrowder, work has started on the proposal, and here is a quick thought about the suggested addition:

Here's the thing: Podlite is supposed to be "purely descriptive" - no presentation stuff, just semantic markup. But "pagebreak" is... well, it's literally about how things render on a page.

Would you be open to renaming it to something more semantic?

For example:

Option 1: =boundary

=boundary
=for boundary :caption<End of Chapter 1>

Option 2: =division

=division
=for division :caption<Part II Begins>

cons: might sound math-y though

Inline variant

not fully sure about using inline variant for =boundary block here.
it was not part of the original request, so it may not be needed.
the available options are G<> and Y<> (Q<> is planned for a new feature),

Example for:
G<> code ("structural gap between line units")
syntax:

=begin para
first lineG<>second line

address:G<>
123 main streetG<>
springfield, il 62701
=end para

does this look good to you?
any concerns or suggestions for improvement?

thank you

[tbrowder]

On Sun, Jan 11, 2026 at 15:50 Alexandr Zahatski ***@***.***> wrote: 👋 @tbrowder <https://github.com/tbrowder>, work has started on your proposal, and here is a draft of the suggested addition:

All of that works for me. Thanks.

…

-Tom

[zag]

Hi @tbrowder ! 👋

I’ve been digging deeper into the implementation details for
line breaks, and I wanted to share a quick update regarding
the inline variant (=boundary) we discussed.

To be honest, the inline code suggestion was entirely my
initiative. Since it wasn't part of your original request,
I’m not even sure if it’s practically required for your
workflow. I’m fully ready to drop it because it doesn't fit
the semantic approach we're aiming for.

There is a strong architectural argument here: in purely
semantic markup, you almost never need to force a hard line
break inside a standard flowing paragraph. If a break is
needed, it usually implies a new thought (a new paragraph)
or a distinct element (a list =item). Forcing a break in the
middle of prose is often just a "presentation hack", which
Podlite tries to avoid.

If we do need to support specific cases like addresses,
poetry, or something like this, those are actually structural properties of
the entire block.

So, instead of cluttering the source with imperative tags
like 123 Main St.G<>City, a cleaner, more semantic solution
would be to apply an attribute to the block - likely named
:lined - to indicate that the line structure within that block
is significant.

Here is how it would look:

  =begin para :lined
  address:
  John Doe                                                    
  123 Main Street                                             
  Springfield, IL 62701  
  =end para

This approach keeps the source text clean (it looks just
like the output) and avoids polluting the content with
layout instructions.

What do you think about swapping the inline code idea for
this attribute-based approach (or dropping it entirely if
you don't need it ) ?

thank you

[tbrowder]

I'm not sure about either, although the block para seems useful.

I think some kind of line break is needed for PDF text since para chunks will have to be typeset to print and it may have to be adjusted as the text is analyzed.

[zag]

Hi @tbrowder 👋

I spent a bit more time thinking this through, and I actually agree with you on this point. while digging into it, I realised that the line break problem is already solved by the existing Podlite specification, without needing to introduce any new markup codes or attributes

Podlite already supports space-preserving text, described here: https://podlite.org/specification#Space-preserving-text

In short, anything wrapped in S<> preserves all whitespace — including newlines:

Any text enclosed in an S<> code is formatted normally, except that every whitespace character in it—including any newline—is preserved. These characters are also treated as being non-breaking (except for the newlines, of course).

That makes it a natural fit for cases like addresses, poetry, or any content where line structure matters

For example:

=begin para
S<address:
John Doe
123 Main Street
Springfield, IL 62701>
=end para

This keeps the markup purely descriptive, while clearly signaling that line structure is significant

As a small extra convenience, you could also add a bit of optional syntactic sugar using aliases:

=alias BR S<
=         >

=para TextA<BR>more text

this improves readability while still relying entirely on existing semantics

hope this approach works for you 🙂
let me know if you see any edge cases where this wouldn’t be sufficient

thank you