\newpage in HTML export

\newpage in HTML export

[Luke Crook]

Both "\newpage" and "#+LATEX: \newpage" generate page breaks in Latex.  
However "\newpage" is included verbatim in HTML export.

Should I use "#+LATEX: \newpage" instead?

/Luke

Re: \newpage in HTML export

[Dan Griswold]

[-- Attachment #1: Type: text/plain, Size: 473 bytes --]

This works well for me:

#+HTML: <div style="page-break-before: always">&nbsp;</div>

placed right where you want the page break.

The break will not appear in the browser, but it will when you print.

Dan



On Wed, Nov 20, 2013 at 1:52 PM, Luke Crook <luke@balooga.com> wrote:

> Both "\newpage" and "#+LATEX: \newpage" generate page breaks in Latex.
> However "\newpage" is included verbatim in HTML export.
>
> Should I use "#+LATEX: \newpage" instead?
>
> /Luke
>
>
>

[-- Attachment #2: Type: text/html, Size: 995 bytes --]

Re: \newpage in HTML export

[Luke Crook]

That works.  But that means I need both #+HTML: and #+Latex: for the same 
thing. \newpage should convert as appropriate depending on the export.

So, \newpage should translate to the HTML equivalent on HTML export, and the 
Latex equivalent on Latex export.

It only works correctly on Latex export

Re: \newpage in HTML export

[Russell Adams]

On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
>
> That works.  But that means I need both #+HTML: and #+Latex: for the same
> thing. \newpage should convert as appropriate depending on the export.
>
> So, \newpage should translate to the HTML equivalent on HTML export, and the
> Latex equivalent on Latex export.
>
> It only works correctly on Latex export

\newpage is a Latex command, and so you need the #+Latex: prefix if
you're exporting to multiple formats. That will prevent it from
happening.

You could use both the #+Latex newpage and the #+HTML snippet together
at the same point to have the same behavior in both modes.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: \newpage in HTML export

[Suvayu Ali]

On Wed, Nov 20, 2013 at 03:20:02PM -0600, Russell Adams wrote:
> On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
> >
> > That works.  But that means I need both #+HTML: and #+Latex: for the same
> > thing. \newpage should convert as appropriate depending on the export.
> >
> > So, \newpage should translate to the HTML equivalent on HTML export, and the
> > Latex equivalent on Latex export.
> >
> > It only works correctly on Latex export
> 
> \newpage is a Latex command, and so you need the #+Latex: prefix if
> you're exporting to multiple formats. That will prevent it from
> happening.

To add a historical comment, eventhough Org claims to be backend
neutral, it treats LaTeX preferencially in practice.  e.g. many common
LaTeX commands/macros are "understood" by Org.

Just follow what Russel said, put them both where you need a pagebreak.
Try this:

#+MACRO: pagebreak @@latex:\newpage@@ @@html:<div style="page-break-before: always">&nbsp;</div>@@

{{{pagebreak}}}

Hope this helps,

-- 
Suvayu

Open source is the future. It sets us free.

Re: \newpage in HTML export

[Eric Abrahamsen]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Wed, Nov 20, 2013 at 03:20:02PM -0600, Russell Adams wrote:
>> On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
>> >
>> > That works.  But that means I need both #+HTML: and #+Latex: for the same
>> > thing. \newpage should convert as appropriate depending on the export.
>> >
>> > So, \newpage should translate to the HTML equivalent on HTML export, and the
>> > Latex equivalent on Latex export.
>> >
>> > It only works correctly on Latex export
>> 
>> \newpage is a Latex command, and so you need the #+Latex: prefix if
>> you're exporting to multiple formats. That will prevent it from
>> happening.
>
> To add a historical comment, eventhough Org claims to be backend
> neutral, it treats LaTeX preferencially in practice.  e.g. many common
> LaTeX commands/macros are "understood" by Org.
>
> Just follow what Russel said, put them both where you need a pagebreak.
> Try this:
>
> #+MACRO: pagebreak @@latex:\newpage@@ @@html:<div style="page-break-before: always">&nbsp;</div>@@
>
> {{{pagebreak}}}
>
> Hope this helps,

Emacs already has the concept of the page-delimiter (defaults to ^L),
for page-related commands. I once floated the idea of making a
page-break a full org element, that could be handled differently by
different backends. I think I made it sound too complicated, though.
Anyway, that's still a possibility.

Re: \newpage in HTML export

[Jambunathan K]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Emacs already has the concept of the page-delimiter (defaults to ^L),
> for page-related commands. I once floated the idea of making a
> page-break a full org element, that could be handled differently by
> different backends.

You are not alone.

The ODT model would be to create a Paragraph style with page-break
before or after.  It is not a standalone element but a special type of
paragraph.

http://lists.gnu.org/archive/html/emacs-orgmode/2013-08/msg00568.html

I have introduced #+PAGEBREAK and also #+ATTR_ODT: :style "whatever" for
specifically this purpose.

> I think I made it sound too complicated, though.

It is difficult to argue with Nicolas.

He has written down a list of things he want to accomplish somewhere.
Unless your suggestion is a bug or contributes to his list, he is
unlikely to consider it.

> Anyway, that's still a possibility.

Ok. Ok.

Re: \newpage in HTML export

[Suvayu Ali]

On Thu, Nov 21, 2013 at 08:11:50AM +0700, Eric Abrahamsen wrote:
> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
> 
> > On Wed, Nov 20, 2013 at 03:20:02PM -0600, Russell Adams wrote:
> >> On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
> >> >
> >> > That works.  But that means I need both #+HTML: and #+Latex: for the same
> >> > thing. \newpage should convert as appropriate depending on the export.
> >> >
> >> > So, \newpage should translate to the HTML equivalent on HTML export, and the
> >> > Latex equivalent on Latex export.
> >> >
> >> > It only works correctly on Latex export
> >> 
> >> \newpage is a Latex command, and so you need the #+Latex: prefix if
> >> you're exporting to multiple formats. That will prevent it from
> >> happening.
> >
> > To add a historical comment, eventhough Org claims to be backend
> > neutral, it treats LaTeX preferencially in practice.  e.g. many common
> > LaTeX commands/macros are "understood" by Org.
> >
> > Just follow what Russel said, put them both where you need a pagebreak.
> > Try this:
> >
> > #+MACRO: pagebreak @@latex:\newpage@@ @@html:<div style="page-break-before: always">&nbsp;</div>@@
> >
> > {{{pagebreak}}}
> >
> > Hope this helps,
> 
> Emacs already has the concept of the page-delimiter (defaults to ^L),
> for page-related commands. I once floated the idea of making a
> page-break a full org element, that could be handled differently by
> different backends. I think I made it sound too complicated, though.
> Anyway, that's still a possibility.

This sounds like good idea.

-- 
Suvayu

Open source is the future. It sets us free.

Re: \newpage in HTML export

[Eric Abrahamsen]

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> On Thu, Nov 21, 2013 at 08:11:50AM +0700, Eric Abrahamsen wrote:
>> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>> 
>> > On Wed, Nov 20, 2013 at 03:20:02PM -0600, Russell Adams wrote:
>> >> On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
>> >> >
>> >> > That works.  But that means I need both #+HTML: and #+Latex: for the same
>> >> > thing. \newpage should convert as appropriate depending on the export.
>> >> >
>> >> > So, \newpage should translate to the HTML equivalent on HTML export, and the
>> >> > Latex equivalent on Latex export.
>> >> >
>> >> > It only works correctly on Latex export
>> >> 
>> >> \newpage is a Latex command, and so you need the #+Latex: prefix if
>> >> you're exporting to multiple formats. That will prevent it from
>> >> happening.
>> >
>> > To add a historical comment, eventhough Org claims to be backend
>> > neutral, it treats LaTeX preferencially in practice.  e.g. many common
>> > LaTeX commands/macros are "understood" by Org.
>> >
>> > Just follow what Russel said, put them both where you need a pagebreak.
>> > Try this:
>> >
>> > #+MACRO: pagebreak @@latex:\newpage@@ @@html:<div style="page-break-before: always">&nbsp;</div>@@
>> >
>> > {{{pagebreak}}}
>> >
>> > Hope this helps,
>> 
>> Emacs already has the concept of the page-delimiter (defaults to ^L),
>> for page-related commands. I once floated the idea of making a
>> page-break a full org element, that could be handled differently by
>> different backends. I think I made it sound too complicated, though.
>> Anyway, that's still a possibility.
>
> This sounds like good idea.

Let me see if I can dig up my original patch. Plebiscite!

[PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 2263 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>
>> On Thu, Nov 21, 2013 at 08:11:50AM +0700, Eric Abrahamsen wrote:
>>> Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:
>>> 
>>> > On Wed, Nov 20, 2013 at 03:20:02PM -0600, Russell Adams wrote:
>>> >> On Wed, Nov 20, 2013 at 09:15:43PM +0000, Luke Crook wrote:
>>> >> >
>>> >> > That works.  But that means I need both #+HTML: and #+Latex: for the same
>>> >> > thing. \newpage should convert as appropriate depending on the export.
>>> >> >
>>> >> > So, \newpage should translate to the HTML equivalent on HTML export, and the
>>> >> > Latex equivalent on Latex export.
>>> >> >
>>> >> > It only works correctly on Latex export
>>> >> 
>>> >> \newpage is a Latex command, and so you need the #+Latex: prefix if
>>> >> you're exporting to multiple formats. That will prevent it from
>>> >> happening.
>>> >
>>> > To add a historical comment, eventhough Org claims to be backend
>>> > neutral, it treats LaTeX preferencially in practice.  e.g. many common
>>> > LaTeX commands/macros are "understood" by Org.
>>> >
>>> > Just follow what Russel said, put them both where you need a pagebreak.
>>> > Try this:
>>> >
>>> > #+MACRO: pagebreak @@latex:\newpage@@ @@html:<div style="page-break-before: always">&nbsp;</div>@@
>>> >
>>> > {{{pagebreak}}}
>>> >
>>> > Hope this helps,
>>> 
>>> Emacs already has the concept of the page-delimiter (defaults to ^L),
>>> for page-related commands. I once floated the idea of making a
>>> page-break a full org element, that could be handled differently by
>>> different backends. I think I made it sound too complicated, though.
>>> Anyway, that's still a possibility.
>>
>> This sounds like good idea.
>
> Let me see if I can dig up my original patch. Plebiscite!

Here's a fairly simple first stab, with page breaks made into an
element, and a sample handling in the LaTeX backend. I've hardcoded ^L
and the page-delimiter regexp that finds it, not sure it's worth
providing an org-page-delimiter shadow. For now, use C-q C-l to insert
the control character.

If this passes muster I can go through the other backends and add
page-break handling where it makes sense. If not, I'll just keep it on
my local branch!

E


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Preliminary-page-break-proposal.patch --]
[-- Type: text/x-diff, Size: 5243 bytes --]

From 377f447623756c5bf07302d99004678e2bfba135 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Fri, 22 Nov 2013 14:41:28 +0700
Subject: [PATCH] Preliminary page break proposal

---
 lisp/org-element.el | 50 +++++++++++++++++++++++++++++++++++++++++++-------
 lisp/ox-latex.el    | 16 ++++++++++++++++
 2 files changed, 59 insertions(+), 7 deletions(-)

diff --git a/lisp/org-element.el b/lisp/org-element.el
index 57e26ff..3e2affb 100644
--- a/lisp/org-element.el
+++ b/lisp/org-element.el
@@ -48,10 +48,10 @@
 ;; Other element types are: `babel-call', `clock', `comment',
 ;; `comment-block', `diary-sexp', `example-block', `export-block',
 ;; `fixed-width', `horizontal-rule', `keyword', `latex-environment',
-;; `node-property', `paragraph', `planning', `quote-section',
-;; `src-block', `table', `table-row' and `verse-block'.  Among them,
-;; `paragraph' and `verse-block' types can contain Org objects and
-;; plain text.
+;; `node-property', `page-break', `paragraph', `planning',
+;; `quote-section', `src-block', `table', `table-row' and
+;; `verse-block'.  Among them, `paragraph' and `verse-block' types can
+;; contain Org objects and plain text.
 ;;
 ;; Objects are related to document's contents.  Some of them are
 ;; recursive.  Associated types are of the following: `bold', `code',
@@ -174,8 +174,8 @@ is not sufficient to know if point is at a paragraph ending.  See
   '(babel-call center-block clock comment comment-block diary-sexp drawer
 	       dynamic-block example-block export-block fixed-width
 	       footnote-definition headline horizontal-rule inlinetask item
-	       keyword latex-environment node-property paragraph plain-list
-	       planning property-drawer quote-block quote-section section
+	       keyword latex-environment node-property page-break paragraph
+	       plain-list planning property-drawer quote-block quote-section section
 	       special-block src-block table table-row verse-block)
   "Complete list of element types.")
 
@@ -204,7 +204,7 @@ regexp matching one object can also match the other object.")
 
 (defconst org-element-all-objects
   '(bold code entity export-snippet footnote-reference inline-babel-call
-	 inline-src-block italic line-break latex-fragment link macro
+	 inline-src-block italic line-break latex-fragment link macro page-break
 	 radio-target statistics-cookie strike-through subscript superscript
 	 table-cell target timestamp underline verbatim)
   "Complete list of object types.")
@@ -2051,6 +2051,40 @@ CONTENTS is nil."
 	  (org-element-property :value node-property)))
 
 
+;;;; Page Break
+
+(defun org-element-page-break-parser (limit affiliated)
+  "Parse a page break.
+
+LIMIT bounds the search.  AFFILIATED is a list of which CAR is
+the buffer position at the beginning of the first affiliated
+keyword and CDR is a plist of affiliated keywords along with
+their value.
+
+Return a list whose CAR is `page-break' and CDR is a plist
+containing `:begin', `:end', `:post-blank' and `:post-affiliated'
+keywords.
+"
+  (save-excursion
+    (let ((begin (car affiliated))
+	  (post-affiliated (point))
+	  (post-pb (progn (forward-line) (point)))
+	  (end (progn (skip-chars-forward " \r\t\n" limit)
+		      (if (eobp) (point) (line-beginning-position)))))
+      (list 'page-break
+	    (nconc
+	     (list :begin begin
+		   :end end
+		   :post-blank (count-lines post-pb end)
+		   :post-affiliated post-affiliated)
+	     (cdr affiliated))))))
+
+(defun org-element-page-break-interpreter (page-break contents)
+  "Interpret PAGE-BREAK element as Org syntax.
+CONTENTS is nil."
+  "\f")
+
+
 ;;;; Paragraph
 
 (defun org-element-paragraph-parser (limit affiliated)
@@ -3845,6 +3879,8 @@ element it has to parse."
 	     ;; Horizontal Rule.
 	     ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
 	      (org-element-horizontal-rule-parser limit affiliated))
+	     ((looking-at page-delimiter)
+	      (org-element-page-break-parser limit affiliated))
 	     ;; Diary Sexp.
 	     ((looking-at "%%(")
 	      (org-element-diary-sexp-parser limit affiliated))
diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 3faeb53..2cf26b1 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -67,6 +67,7 @@
     (link . org-latex-link)
     (node-property . org-latex-node-property)
     (paragraph . org-latex-paragraph)
+    (page-break . org-latex-page-break)
     (plain-list . org-latex-plain-list)
     (plain-text . org-latex-plain-text)
     (planning . org-latex-planning)
@@ -379,6 +380,13 @@ which format headlines like for Org version prior to 8.0."
   :type 'string)
 
 
+;;;; Page Breaks
+
+(defcustom org-latex-default-page-break "\\newpage"
+  "Default page break type."
+  :group 'org-export-latex
+  :type 'string)
+
 ;;;; Timestamps
 
 (defcustom org-latex-active-timestamp-format "\\textit{%s}"
@@ -1865,6 +1873,14 @@ the plist used as a communication channel."
   contents)
 
 
+;;;; Page Break
+
+(defun org-latex-page-break (page-break contents info)
+  "Transcode a PAGE-BREAK 3element from Org to LaTeX.
+CONTENTS is nil.  INFO is the plist used as a communication
+channel."
+  org-latex-default-page-break)
+
 ;;;; Plain List
 
 (defun org-latex-plain-list (plain-list contents info)
-- 
1.8.4.2

Re: [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Here's a fairly simple first stab, with page breaks made into an
> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
> and the page-delimiter regexp that finds it, not sure it's worth
> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
> the control character.

Thanks for the patch.

Anyway, I don't think this is a good idea to introduce a new syntax just
to avoid a one-liner (or a hook, see below). Also, this would only make
sense in few export back-ends.

Really, introducing new syntax has a cost, so you have to ponder if it's
really useful, because, once installed, every Org user will have to pay
the price for it.

In the same vein, we have a couple of dubious syntactical elements which
probably sound great for a few users but don't make much sense in most
cases (e.g. quote sections, which can be replaced with an example(!)
block and comments blocks, which can be replaced with a regular
comment).

Admittedly, in this particular case, that cost isn't very high, but
I think it would nonetheless add up to the list of hardly-used syntax
category.

> If this passes muster I can go through the other backends and add
> page-break handling where it makes sense. If not, I'll just keep it on
> my local branch!

You don't need such a patch. For example, you can install the following:

  (defun my-page-delimiter-hook (backend)
    (while (re-search-forward page-delimiter nil t)
      (replace-match
       (cond
        ((org-export-derived-backend-p backend 'latex)
         "#+LATEX: \\\\newpage")
        ((org-export-derived-backend-p backend 'html)
         "#+HTML: <div style=\"page-break-before: always\">&nbsp;</div>")
        ;; Ignore page delimiters in other back-ends.
        (t "")))))

  (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)

Obviously, you can handle as many back-ends as you see fit in
`my-page-delimiter-hook'.

Here are a few comments about the code:

>  (defconst org-element-all-objects
>    '(bold code entity export-snippet footnote-reference inline-babel-call
> -	 inline-src-block italic line-break latex-fragment link macro
> +	 inline-src-block italic line-break latex-fragment link macro page-break
>  	 radio-target statistics-cookie strike-through subscript superscript
>  	 table-cell target timestamp underline verbatim)
>    "Complete list of object types.")

Since `page-break' is an element type, you cannot make it also an object
type.

Also, you would need to update `org-element-paragraph-separate' regexp.

>  (defun org-element-paragraph-parser (limit affiliated)
> @@ -3845,6 +3879,8 @@ element it has to parse."
>  	     ;; Horizontal Rule.
>  	     ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
>  	      (org-element-horizontal-rule-parser limit affiliated))
> +	     ((looking-at page-delimiter)
> +	      (org-element-page-break-parser limit affiliated))

Using `page-delimiter' is not desirable because it implies that its
syntax is customizable, which would go against the last syntax patches
(changing defcustoms into defconsts whenever possible). Customizable
syntax cripples portability: please use it with care.


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Re: \newpage in HTML export

[Rüdiger Sonderfeld]

On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.

But is it really a new syntax or just support for an existing Emacs 
convention?  See (info "(emacs) Pages").

It seems like a feature which could be supported in many back-ends: LaTeX, 
ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.

Regards,
Rüdiger

Re: [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:

> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>> Anyway, I don't think this is a good idea to introduce a new syntax just
>> to avoid a one-liner (or a hook, see below). Also, this would only make
>> sense in few export back-ends.
>
> But is it really a new syntax or just support for an existing Emacs 
> convention?  See (info "(emacs) Pages").
>
> It seems like a feature which could be supported in many back-ends: LaTeX, 
> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.

I do not question this.

My point is that introducing this new syntax would bring up nothing that
can already be achieved using filters or hooks.

So, is this feature a must-have? Or would a filter template in Worg more
appropriate in this case?


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
> Hello,
>
> Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:
>
>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>>> Anyway, I don't think this is a good idea to introduce a new syntax just
>>> to avoid a one-liner (or a hook, see below). Also, this would only make
>>> sense in few export back-ends.
>>
>> But is it really a new syntax or just support for an existing Emacs 
>> convention?  See (info "(emacs) Pages").
>>
>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>
> I do not question this.
>
> My point is that introducing this new syntax would bring up nothing that
> can already be achieved using filters or hooks.
>
> So, is this feature a must-have? Or would a filter template in Worg more
> appropriate in this case?

It's not that everyone is desperate to have this in org proper. Putting
it into the code base vs making a hook: my guess is the number of LOC
would be very nearly exactly the same, and there's literally no
practical difference in the result. When "why" and "why not" are
perfectly balanced, it may be better to do nothing.

But I think it just *feels* right, because the page delimiter already
seems like a first-class citizen in emacs. I'll admit it's also
partially because it's a control character. Control character! Must be
serious programming. I also like the thought of a new org user sticking
one in their document, exporting, and finding that org does the right
thing.

At this point, I'm pretty much neutral buoyancy on the issue, though...

Eric

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> On 11/24/13 16:31 PM, Nicolas Goaziou wrote:
>> Hello,
>>
>> Rüdiger Sonderfeld <ruediger@c-plusplus.de> writes:
>>
>>> On Friday 22 November 2013 11:24:17 Nicolas Goaziou wrote:
>>>> Anyway, I don't think this is a good idea to introduce a new syntax just
>>>> to avoid a one-liner (or a hook, see below). Also, this would only make
>>>> sense in few export back-ends.
>>>
>>> But is it really a new syntax or just support for an existing Emacs 
>>> convention?  See (info "(emacs) Pages").
>>>
>>> It seems like a feature which could be supported in many back-ends: LaTeX, 
>>> ODT, HTML, Texinfo, Ascii, Org, (Groff), maybe even md with pandoc.
>>
>> I do not question this.
>>
>> My point is that introducing this new syntax would bring up nothing that
>> can already be achieved using filters or hooks.
>>
>> So, is this feature a must-have? Or would a filter template in Worg more
>> appropriate in this case?
>
> It's not that everyone is desperate to have this in org proper. Putting
> it into the code base vs making a hook: my guess is the number of LOC
> would be very nearly exactly the same, and there's literally no
> practical difference in the result. When "why" and "why not" are
> perfectly balanced, it may be better to do nothing.
>
> But I think it just *feels* right, because the page delimiter already
> seems like a first-class citizen in emacs. I'll admit it's also
> partially because it's a control character. Control character! Must be
> serious programming. I also like the thought of a new org user sticking
> one in their document, exporting, and finding that org does the right
> thing.
>
> At this point, I'm pretty much neutral buoyancy on the issue, though...
>

I (as a user, so not carrying the maintenance burden of any added
feature) am in favor of having this feature in org directly.

I think many people that use some of the export functionality will need
to control page breaks at some point.  If this is not supported by org,
most of them will have (as I did until now) backend specific page breaks
in their org mode files (maybe multiple, as suggested earlier in this
thread), which is the inferior solution.

A possible argument against the filter solution is, that an org file that
relies on the presence of a filter is less portable.

And I do not agree with 'the number of LOC would be very nearly exactly
the same' as the filter has to be copy-pasted by every one who wants to
use it ;-)


So in short:  If page breaks are not in org directly many people will
end up with inferior and/or less portable org files.



- Andreas

Re: [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> So in short:  If page breaks are not in org directly many people will
> end up with inferior and/or less portable org files.

For the record, after thinking about it, I'd rather stay away from
invisible characters in Org syntax, would it be page breaks or
non-breaking spaces.

Porting an Org file requires to also to port Org configuration. A filter
is enough to support these characters. Added support would just be, IMO,
"coolishness".


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> So in short:  If page breaks are not in org directly many people will
>> end up with inferior and/or less portable org files.
>
> For the record, after thinking about it, I'd rather stay away from
> invisible characters in Org syntax, would it be page breaks or
> non-breaking spaces.

I agree about the invisible characters.

>
> Porting an Org file requires to also to port Org configuration. A filter
> is enough to support these characters. Added support would just be, IMO,
> "coolishness".

Just for me to understand:
The recommended way now is to have a filter and write (say) \mypersonalnewline
in my orgmode files?  Even if \mypersonalnewline won't work for anyone
except myself?  Or did I miss something?

Regards,
Andreas

Re: [PATCH] Re: \newpage in HTML export

[Nicolas Goaziou]

Hello,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Just for me to understand:
> The recommended way now

Note that the recommended way hasn't really changed. There was no
recommended way before, nor there is one now.

> is to have a filter and write (say) \mypersonalnewline in my orgmode
> files? Even if \mypersonalnewline won't work for anyone except myself?
> Or did I miss something?

You can write ^L in your files, as long as you transform it into
something useful, through a filter.

It will work for anyone with whom you share your Org configuration, or,
at least, anyone using an equivalent filter.


Regards,

-- 
Nicolas Goaziou

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> Just for me to understand:
>> The recommended way now
>
> Note that the recommended way hasn't really changed. There was no
> recommended way before, nor there is one now.
>

;-)

>> is to have a filter and write (say) \mypersonalnewline in my orgmode
>> files? Even if \mypersonalnewline won't work for anyone except myself?
>> Or did I miss something?
>
> You can write ^L in your files, as long as you transform it into
> something useful, through a filter.
>

I am not interested in ^L in particular.  I am interested in a
pagebreak, that works across backends.  My filter will not use '^L' but
rather '\newpage'.

> It will work for anyone with whom you share your Org configuration, or,
> at least, anyone using an equivalent filter.

Ok.  So be it.

Regards,
Andreas

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

>> So in short:  If page breaks are not in org directly many people will
>> end up with inferior and/or less portable org files.
>
> For the record, after thinking about it, I'd rather stay away from
> invisible characters in Org syntax, would it be page breaks or
> non-breaking spaces.

FWIW I fully support not using invisible chars in Org syntax.

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Bastien <bzg@gnu.org> writes:

> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>
>>> So in short:  If page breaks are not in org directly many people will
>>> end up with inferior and/or less portable org files.
>>
>> For the record, after thinking about it, I'd rather stay away from
>> invisible characters in Org syntax, would it be page breaks or
>> non-breaking spaces.
>
> FWIW I fully support not using invisible chars in Org syntax.

This follows up on just a side aspect in this thread that is (partly)
separate from its subject.


Just to wrap the thread up in my words:

1. Cross-backend (or more cross-backend) support of \newpage built into
   Org directly was disapproved in favor of a less portable filter based
   solution [fn:1].

2. Introducing invisible chars (as syntax for a possible implementation
   of such cross backend \newpage) in Org syntax was generally
   disapproved.

Regards,
Andreas


Footnotes:

[fn:1] http://permalink.gmane.org/gmane.emacs.orgmode/79164

Re: [PATCH] Re: \newpage in HTML export

[Thomas S. Dye]

Aloha Andreas,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> Bastien <bzg@gnu.org> writes:
>
>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>
>>>> So in short:  If page breaks are not in org directly many people will
>>>> end up with inferior and/or less portable org files.
>>>
>>> For the record, after thinking about it, I'd rather stay away from
>>> invisible characters in Org syntax, would it be page breaks or
>>> non-breaking spaces.
>>
>> FWIW I fully support not using invisible chars in Org syntax.
>
> This follows up on just a side aspect in this thread that is (partly)
> separate from its subject.
>
>
> Just to wrap the thread up in my words:
>
> 1. Cross-backend (or more cross-backend) support of \newpage built into
>    Org directly was disapproved in favor of a less portable filter based
>    solution [fn:1].

Could you expand on what you mean by "less portable"? I'm interested in
portability from a reproducible research perspective and want to avoid
habits that don't port well to other researchers' systems.

Happy New Year!

-- 
Thomas S. Dye
http://www.tsdye.com

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Hi Tom,

tsd@tsdye.com (Thomas S. Dye) writes:

> Aloha Andreas,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> Bastien <bzg@gnu.org> writes:
>>
>>> Nicolas Goaziou <n.goaziou@gmail.com> writes:
>>>
>>>>> So in short:  If page breaks are not in org directly many people will
>>>>> end up with inferior and/or less portable org files.
>>>>
>>>> For the record, after thinking about it, I'd rather stay away from
>>>> invisible characters in Org syntax, would it be page breaks or
>>>> non-breaking spaces.
>>>
>>> FWIW I fully support not using invisible chars in Org syntax.
>>
>> This follows up on just a side aspect in this thread that is (partly)
>> separate from its subject.
>>
>>
>> Just to wrap the thread up in my words:
>>
>> 1. Cross-backend (or more cross-backend) support of \newpage built into
>>    Org directly was disapproved in favor of a less portable filter based
>>    solution [fn:1].
>
> Could you expand on what you mean by "less portable"? I'm interested in
> portability from a reproducible research perspective and want to avoid
> habits that don't port well to other researchers' systems.
>

I did not want to include these words in the first place.  The words 'less
portable' are too strong here.

You won't be affected, since you ship your emacs / Org configuration
with the document, IIUC.  (Which is the only possible way to achieve
something like reproducibility with Org...)
In that case you can simply include such a filter in that configuration.


The non-portable part comes from the need to share that filter.
Anybody without that filter will not be able to export your document in
the intended way.


Just to clarify:
It is a very small thing and I am very much happy with using a filter based
approach here.

> Happy New Year!
Same to you!

Regards,
Andreas

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

Hi Andreas,

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> It is a very small thing and I am very much happy with using a filter based
> approach here.

One thing really worth improving is the tutorials around filters on
Worg.  Or maybe: let's create a place similar to org-hacks.org called
org-filters.org listing useful filters.

Any taker?

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Andreas Leha]

Bastien <bzg@gnu.org> writes:

> Hi Andreas,
>
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
>
>> It is a very small thing and I am very much happy with using a filter based
>> approach here.
>
> One thing really worth improving is the tutorials around filters on
> Worg.  Or maybe: let's create a place similar to org-hacks.org called
> org-filters.org listing useful filters.

I agree.  an org-filters collection would be awesome!

>
> Any taker?

Not me, I am afraid, since I am completely out of time right now(so that
I should actually not read or write anything on this list...).

I am very sorry -- would have been a nice way to contribute.

Regards,
Andreas

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:

> I am very sorry -- would have been a nice way to contribute.

No problem, I just wanted to verbalize this wish so that someone
with more time at hand can take the challenge :)

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Suvayu Ali]

On Sat, Jan 04, 2014 at 11:40:10AM +0100, Bastien wrote:
> Hi Andreas,
> 
> Andreas Leha <andreas.leha@med.uni-goettingen.de> writes:
> 
> > It is a very small thing and I am very much happy with using a filter based
> > approach here.
> 
> One thing really worth improving is the tutorials around filters on
> Worg.  Or maybe: let's create a place similar to org-hacks.org called
> org-filters.org listing useful filters.

It already exists:

  <http://orgmode.org/worg/exporters/filter-markup.html>

Maybe this can be improved?

-- 
Suvayu

Open source is the future. It sets us free.

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

Hi Suvayu,

Suvayu Ali <fatkasuvayu+linux@gmail.com> writes:

> It already exists:
>
>   <http://orgmode.org/worg/exporters/filter-markup.html>
>
> Maybe this can be improved?

This is the documentation for export filters, with some example.

But it is not clear that this page welcome new contributed
filters, and I think it does not.

I think having another page would help.

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Sebastien Vauban]

Andreas Leha wrote:
>> Could you expand on what you mean by "less portable"? I'm interested in
>> portability from a reproducible research perspective and want to avoid
>> habits that don't port well to other researchers' systems.
>>
>
> I did not want to include these words in the first place.  The words 'less
> portable' are too strong here.
>
> You won't be affected, since you ship your emacs / Org configuration
> with the document, IIUC.  (Which is the only possible way to achieve
> something like reproducibility with Org...)
> In that case you can simply include such a filter in that configuration.
>
> The non-portable part comes from the need to share that filter.
> Anybody without that filter will not be able to export your document in
> the intended way.

Shouldn't, then, some filters be available by default in core Org?

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

"Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> Shouldn't, then, some filters be available by default in core Org?

I don't think so: my understanding is that "default filters" would
then be implemented without relying on filters -- so filters are
really optional by nature.  Nicolas will correct me if I'm wrong.

But building a page on Worg listing useful filters is a separate
task, and a good one.

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Sebastien Vauban]

Hello Bastien,

Bastien wrote:
> "Sebastien Vauban" writes:
>
>> Shouldn't, then, some filters be available by default in core Org?
>
> I don't think so: my understanding is that "default filters" would
> then be implemented without relying on filters -- so filters are
> really optional by nature. Nicolas will correct me if I'm wrong.
>
> But building a page on Worg listing useful filters is a separate task,
> and a good one.

The thing is that, IMHO, there are 2 types of filters required:

- filters for my own additions to Org syntax, that I don't need (or
  want) to share with anybody

- filters for "missing" Org syntax which seems a need that many users
  have at some point

The \newpage stuff, AFAIU, falls in the second category. This question
came a couple of times already on this ML, hence my suggestion to offer
it in a more standard way -- without just telling "go on Worg, copy some
snippet you'd find, paste it in your .emacs, and tell your colleagues to
do the same".

Best regards,
  Seb

-- 
Sebastien Vauban

Re: [PATCH] Re: \newpage in HTML export

[Bastien]

"Sebastien Vauban" <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org>
writes:

> The thing is that, IMHO, there are 2 types of filters required:
>
> - filters for my own additions to Org syntax, that I don't need (or
>   want) to share with anybody
>
> - filters for "missing" Org syntax which seems a need that many users
>   have at some point
>
> The \newpage stuff, AFAIU, falls in the second category. This question
> came a couple of times already on this ML, hence my suggestion to offer
> it in a more standard way -- without just telling "go on Worg, copy some
> snippet you'd find, paste it in your .emacs, and tell your colleagues to
> do the same".

Yes, that's why I suggest filters to be only for local customizations,
while "filters-needed-by-many-users" should really be in the code (and
probably not as filters.)

But still, a place to find and learn about filters would be nice.

-- 
 Bastien

Re: [PATCH] Re: \newpage in HTML export

[Christian Moe]

Nicolas Goaziou writes:
> So, is this feature a must-have? 

No, it's not. (Just another user's ten cents.)

> Or would a filter template in Worg more appropriate in this case?

That, or showing how to make a {{{pagebreak}}} macro expanding to export
snippets. (And explaining how regular page breaks before new chapters
etc. are anyway better handled by styles in ODT and HTML-for-print.)

Yours,
Christian

Re: [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Here's a fairly simple first stab, with page breaks made into an
>> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
>> and the page-delimiter regexp that finds it, not sure it's worth
>> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
>> the control character.
>
> Thanks for the patch.
>
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.
>
> Really, introducing new syntax has a cost, so you have to ponder if it's
> really useful, because, once installed, every Org user will have to pay
> the price for it.
>
> In the same vein, we have a couple of dubious syntactical elements which
> probably sound great for a few users but don't make much sense in most
> cases (e.g. quote sections, which can be replaced with an example(!)
> block and comments blocks, which can be replaced with a regular
> comment).
>
> Admittedly, in this particular case, that cost isn't very high, but
> I think it would nonetheless add up to the list of hardly-used syntax
> category.
>
>> If this passes muster I can go through the other backends and add
>> page-break handling where it makes sense. If not, I'll just keep it on
>> my local branch!
>
> You don't need such a patch. For example, you can install the following:
>
>   (defun my-page-delimiter-hook (backend)
>     (while (re-search-forward page-delimiter nil t)
>       (replace-match
>        (cond
>         ((org-export-derived-backend-p backend 'latex)
>          "#+LATEX: \\\\newpage")
>         ((org-export-derived-backend-p backend 'html)
>          "#+HTML: <div style=\"page-break-before: always\">&nbsp;</div>")
>         ;; Ignore page delimiters in other back-ends.
>         (t "")))))
>
>   (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)
>
> Obviously, you can handle as many back-ends as you see fit in
> `my-page-delimiter-hook'.
>
> Here are a few comments about the code:
>
>>  (defconst org-element-all-objects
>>    '(bold code entity export-snippet footnote-reference inline-babel-call
>> -	 inline-src-block italic line-break latex-fragment link macro
>> +	 inline-src-block italic line-break latex-fragment link macro page-break
>>  	 radio-target statistics-cookie strike-through subscript superscript
>>  	 table-cell target timestamp underline verbatim)
>>    "Complete list of object types.")
>
> Since `page-break' is an element type, you cannot make it also an object
> type.
>
> Also, you would need to update `org-element-paragraph-separate' regexp.
>
>>  (defun org-element-paragraph-parser (limit affiliated)
>> @@ -3845,6 +3879,8 @@ element it has to parse."
>>  	     ;; Horizontal Rule.
>>  	     ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
>>  	      (org-element-horizontal-rule-parser limit affiliated))
>> +	     ((looking-at page-delimiter)
>> +	      (org-element-page-break-parser limit affiliated))
>
> Using `page-delimiter' is not desirable because it implies that its
> syntax is customizable, which would go against the last syntax patches
> (changing defcustoms into defconsts whenever possible). Customizable
> syntax cripples portability: please use it with care.

No worries, I'm not terribly married to this, and I do think I do more
multiple-backend export than is the norm. I appreciate the code notes --
I'll admit I was a tiny bit confused about the difference between
element and object. I also wavered between making it a hard-coded
defconst or a fully customizable option, and landed awkwardly in
between.

A hook will probably do me.

Thanks,Eric

Re: [PATCH] Re: \newpage in HTML export

[Eric Abrahamsen]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Hello,
>
> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Here's a fairly simple first stab, with page breaks made into an
>> element, and a sample handling in the LaTeX backend. I've hardcoded ^L
>> and the page-delimiter regexp that finds it, not sure it's worth
>> providing an org-page-delimiter shadow. For now, use C-q C-l to insert
>> the control character.
>
> Thanks for the patch.
>
> Anyway, I don't think this is a good idea to introduce a new syntax just
> to avoid a one-liner (or a hook, see below). Also, this would only make
> sense in few export back-ends.
>
> Really, introducing new syntax has a cost, so you have to ponder if it's
> really useful, because, once installed, every Org user will have to pay
> the price for it.
>
> In the same vein, we have a couple of dubious syntactical elements which
> probably sound great for a few users but don't make much sense in most
> cases (e.g. quote sections, which can be replaced with an example(!)
> block and comments blocks, which can be replaced with a regular
> comment).
>
> Admittedly, in this particular case, that cost isn't very high, but
> I think it would nonetheless add up to the list of hardly-used syntax
> category.
>
>> If this passes muster I can go through the other backends and add
>> page-break handling where it makes sense. If not, I'll just keep it on
>> my local branch!
>
> You don't need such a patch. For example, you can install the following:
>
>   (defun my-page-delimiter-hook (backend)
>     (while (re-search-forward page-delimiter nil t)
>       (replace-match
>        (cond
>         ((org-export-derived-backend-p backend 'latex)
>          "#+LATEX: \\\\newpage")
>         ((org-export-derived-backend-p backend 'html)
>          "#+HTML: <div style=\"page-break-before: always\">&nbsp;</div>")
>         ;; Ignore page delimiters in other back-ends.
>         (t "")))))
>
>   (add-hook 'org-export-before-parsing-hook 'my-page-delimiter-hook)
>
> Obviously, you can handle as many back-ends as you see fit in
> `my-page-delimiter-hook'.
>
> Here are a few comments about the code:
>
>>  (defconst org-element-all-objects
>>    '(bold code entity export-snippet footnote-reference inline-babel-call
>> -	 inline-src-block italic line-break latex-fragment link macro
>> +	 inline-src-block italic line-break latex-fragment link macro page-break
>>  	 radio-target statistics-cookie strike-through subscript superscript
>>  	 table-cell target timestamp underline verbatim)
>>    "Complete list of object types.")
>
> Since `page-break' is an element type, you cannot make it also an object
> type.
>
> Also, you would need to update `org-element-paragraph-separate' regexp.
>
>>  (defun org-element-paragraph-parser (limit affiliated)
>> @@ -3845,6 +3879,8 @@ element it has to parse."
>>  	     ;; Horizontal Rule.
>>  	     ((looking-at "[ \t]*-\\{5,\\}[ \t]*$")
>>  	      (org-element-horizontal-rule-parser limit affiliated))
>> +	     ((looking-at page-delimiter)
>> +	      (org-element-page-break-parser limit affiliated))
>
> Using `page-delimiter' is not desirable because it implies that its
> syntax is customizable, which would go against the last syntax patches
> (changing defcustoms into defconsts whenever possible). Customizable
> syntax cripples portability: please use it with care.

No worries, I'm not terribly married to this, and I do think I do more
multiple-backend export than is the norm. I appreciate the code notes --
I'll admit I was a tiny bit confused about the difference between
element and object. I also wavered between making it a hard-coded
defconst or a fully customizable option, and landed awkwardly in
between.

A hook will probably do me.

Thanks,
Eric

Re: [PATCH] Re: \newpage in HTML export

[Jambunathan K]

You could have used a #+PAGEBREAK and handled it as part of say an
advice to org-BACKEND-keyword in whatever BACKEND you are using.