Re: [bug] Problem with Worg (html?) publishing (was Re: [O] orgmode BEAMER scaling image)

[Nick Dokos]

Nick Dokos <address@hidden> wrote:

> Eric S Fraga <address@hidden> wrote:
> 
> 
> > In the org-beamer tutorial (Worg/org-tutorials/org-beamer/tutorial.org),
> > I have the following:
> > 
> > ,----
> > | 
> > | #+BEGIN_Example
> > | ,** Two columns
> > | 
> > | ,*** A block                                           
> > :B_ignoreheading:BMCOL:
> > |     :PROPERTIES:
> > |     :BEAMER_env: ignoreheading
> > |     :BEAMER_col: 0.4
> > |     :END:
> > |     - this slide consists of two columns
> > |     - the first (left) column has no heading and consists of text
> > |     - the second (right) column has an image and is enclosed in an
> > |       @example@ block
> > | 
> > | ,*** A screenshot                                            
> > :BMCOL:B_example:
> > |     :PROPERTIES:
> > |     :BEAMER_col: 0.6
> > |     :BEAMER_env: example
> > |     :END:
> > | ,    #+ATTR_LATEX: width=\textwidth
> > |     [[file://../../images/org-beamer/a-simple-slide.png]]
> > | #+END_Example
> > `----
> > 
> > Note the second last line of the example which sets the latex attribute
> > for the following image.  On export to HTML for publishing on the Worg
> > website, this line has magically *disappeared*!  The ',' is supposed to
> > protect this line but instead it disappears.
> > 
> > I have gone through the whole tutorial and this is the only line that
> > has disappeared.  My intuition is that the HTML export is ignoring all
> > LATEX attribute lines (as it should) but that maybe the regex for is
> > rather greedy?  However, I have looked at the code but have not seen
> > anywhere obvious where this happens -- all the regexs I found seem to be
> > pinned at the start of the line with only whitespace allowed before
> > the #+.
> > 
> 
> Your intuition is (almost) correct: in org-export-preprocess-string, the comma
> is stripped by org-export-replace-src-segments-and-examples and the
> ATTR_LATEX is stripped by org-export-select-backend-specific-text which 
> very explicitly says:
> 
> ,----
> |       ...
> |       ;; Delete #+attr_Backend: stuff of another backend. Those
> |       ;; matching the current backend will be taken care of by
> |       ;; `org-export-attach-captions-and-attributes'
> |       ...
> `----
> 
> 

Commenting out the two forms that follow this comment preserve the ATTR_LATEX,
but that's obviously not *the* fix:

,----
|       ...
|       ;; Delete #+attr_Backend: stuff of another backend. Those
|       ;; matching the current backend will be taken care of by
|       ;; `org-export-attach-captions-and-attributes'
|       ;; <ND>
|       ;; (goto-char (point-min))
|       ;; (while (re-search-forward (concat "^\\([ \t]*\\)#\\+attr_" (cadr fmt)
|       ;;                                      ":[ \t]*\\(.*\\)") nil t)
|       ;;      (setq ind (org-get-indentation))
|       ;;      (when (not (eq (car fmt) org-export-current-backend))
|       ;;        (delete-region (point-at-bol) (min (1+ (point-at-eol)) 
(point-max)))))
|       ;; </ND>
|       ;; Handle #+begin_backend and #+end_backend stuff
|       ...
`----

It's not clear to me how to fix it properly: at the point where
org-export-select-backend-specific-text is called, there's been a
partial transformation of the input, so the function is looking at the
following:

,----
| 
| #+BEGIN_HTML
| <pre class="example">
| *** A block                                           :B_ignoreheading:BMCOL:
|     :PROPERTIES:
|     :BEAMER_env: ignoreheading
|     :BEAMER_col: 0.4
|     :END:
|     - this slide consists of two columns
|     - the first (left) column has no heading and consists of text
|     - the second (right) column has an image and is enclosed in an
|       @example@ block
| 
| *** A screenshot                                            :BMCOL:B_example:
|     :PROPERTIES:
|     :BEAMER_col: 0.6
|     :BEAMER_env: example
|     :END:
|     #+ATTR_LATEX: width=\textwidth
|     [[file://../../images/org-beamer/a-simple-slide.png]]
| </pre>
| 
| #+END_HTML
| 
`----

It could use the fact that it is in a <pre> section - but the function
is generic wrt backends, so it doesn't worry about details like this.
Maybe a backend-specific function can be called at this point to deal
with it - and that can be smarter about how to transform it properly.

Nick