* lisp/org-html.el (org-export-as-html): Do not treat partially
protected lines as if they were fully protected.
Nicolas Goaziou writes:
> Here is a problem when a latex fragment is split across two lines and
> an emphasize follows. The text won't be italicized upon exporting to
> HTML.
>
> =====
> * latex-fragments bug
>
> Imagine we have a formula starting here $e^{i\pi} +
> 1 = 0$. Now we have a problem with /emphasize/.
> =====
>
> This is because the line starts with a char with 'org-protected
> property and, thus, get caught by the "Protected HTML" (org-html.el
> l. 1216) part of `org-export-as-html'. In others words, the line is
> inserted as-is in the output buffer, before getting any
> transformation.
>
> I'm not sure how it should be done (I don't get yet the usefulness of
> this "Protected HTML" part), but that piece of code may be moved after
> the `org-html-expand' call, as long as every sub-function in
> `org-html-expand' has a check to prevent modifying protected stuff
> (this not yet the case for `org-export-with-emphasize' and
> `org-html-protect' while others seem ok).
>
> But even in this case, every function getting called after that would
> be ignored. So, for example, links would not be inserted.
>
> Couldn't the "Protected HTML" part be removed altogether?
* lisp/org-html.el (org-format-table-html): New argument DOCBOOK.
(org-format-org-table-html): New argument DOCBOOK. When set, use
align instead of class to align table fields.
* lisp/org-docbook.el (org-export-as-docbook): Specify the docbook argument
for the table converter.
* doc/org.texi: Document the <c> cookie.
* lisp/org-exp.el (org-store-forced-table-alignment):
(org-export-remove-special-table-lines): Allow the "c" cookie for
table alignment.
* lisp/org-html.el (org-export-table-header-tags):
(org-export-table-data-tags): Add another %s format for the alignment.
(org-export-html-table-align-individual-fields): New option.
(org-format-org-table-html): Implement field-by-field alignment and
support centering.
(org-format-table-table-html): Make sure the new table tag formats
don't break this function.
* lisp/org-table.el (org-table-cookie-line-p):
(org-table-align): Allow for the <c> cookie.
* lisp/org.el (org-set-font-lock-defaults): Allow for the <c> cookie.
On Wed, Sep 8, 2010 at 2:12 AM, Daniel Clemente <n142857@gmail.com> wrote:
>
> Commit bd1b57f92a broke the exporting
> of [[file:a.org]] links, which now appear as [[http:a.html]]. Try
> C-c C-e H on any .org with such links, even in emacs -Q.
>
> The problem is, I think, that „type“ is actually "http", not "file"
> as the code tries.
>
* lisp/org-html.el (org-html-cvt-org-as-html): Do not convert protocol
from 'file' to 'http'.
TINYCHANGE
Achim Gratz <Stromeko@nexgo.de> writes:
> HTML export removes the "mailto:" from a link, which will then be
> interpreted as a local link by the browser.
>
> For an example, see the link to this mailing list in
> ORGWEBPAGE/index.org and the corresponding HTML export on orgmode-org
> (or just the local file).
>
org-html.el : Fix exporting file, mailto, news and ftp protocols.
* lisp/org-html.el (org-html-make-link): (expand-file-name
) removes one "/" from "///path-to-file", so add one. Anything other
than 'file' type should be exported along with the type.
TINYCHANGE
Thanks and Regards
Noorul
* org-docbook.el (org-export-as-docbook): Removed check for
indentation on lines that do not start with a list bullet.
* org-html.el (org-export-as-html): Same thing.
* org-docbook.el (org-export-as-docbook): Use override="num" in any
listitem matching [@start:num]
* org-html.el (org-export-as-html): Use value="num" in any li matching
[@start:num]
* org-docbook.el (org-export-as-docbook): When we find an empty line,
we do not need to check for `org-empty-line-terminates-plain-lists'
because we would have found end-list marker before.
* org-html.el (org-export-as-html): Same.
* org-html.el (org-export-html-preprocess): Remove unneeded insertion
of list end marker, as it is now handled by
`org-export-mark-list-ending'.
* org-html.el (org-export-as-html): Cleaner termination of lists.
* org-exp.el (org-export-mark-list-ending): New function to insert
specific markers at the end of lists when exporting to a backend not
using `org-list-parse-list'.
This function is called early in `org-export-preprocess-string',
while it is still able to recognize lists.
* org-latex.el (org-export-latex-lists): Better search for lists. It
now only finds items not enclosed and not protected.
* lisp/org-exp.el (org-export-with-LaTeX-fragments): New default t, which
now means to use MathJax processing for HTML. Also allow new value
`dvipng' to force the old image processing.
(org-infile-export-plist): Parse for MATHJAX setup line.
* lisp/org-html.el (org-export-html-mathjax-options): New option.
(org-export-html-mathjax-config): New function.
(org-export-html-mathjax-template): New option.
(org-export-html-preprocess): Call the LaTeX snippet processor with an
additional argument to declare special ways of processing.
(org-export-as-html): Bind the dynamical variable
`org-export-have-math'. Insert the MathJax script template when it is
needed by the document.
* lisp/org.el (org-preview-latex-fragment): Call `org-format-latex' with
the additional processing argument.
(org-export-have-math): New variable, for dynamic scoping.
(org-format-latex): Implement specific ways of processing. New
function argument for processing type.
(org-org-menu): Remove the entry to configure LaTeX snippet
processing.
MathJax is now the default for displaying math in a browser.
This is a second patch in a series that makes some straightforward
corrections to a number of docstrings. Each change is normally to:
- correct a typo, or
- fix up hyperlinks to function or variable names, or
- ensure slightly better conformance with the documentation guidelines
and tips given in the Elisp manual
No attempt is made to provide missing docstrings or document arguments.
Cheers,
Phil
* lisp/org-html.el (org-export-html-preprocess): Call org-format-latex,
possibly with a protect-only argument.
* lisp/org.el (org-format-latex): New argument PROTECT-ONLY.
with the switch #+OPTIONS: LaTeX:verbatim ,
LaTeX code will be exported verbatim to HTML, so that jsmath can grab
and convert it.
Proposed by Christian Moe.
* lisp/org-exp.el (org-export-format-source-code-or-example): Mark examples
by a property. o
* lisp/org-html.el (org-export-html-close-lists-maybe): Check if raw
HTML stuff was actually made from an example
Daniel Mahler writes:
> 2. I would like to embed source blocks in numbered lists, without
> breaking the numbering ie:
>
> 1) get ready
> #+BEGIN_SRC sh
> get_ready
> #+END_SRC
> 2) go
> #+BEGIN_SRC sh
> go
> #+END_SRC
>
> currently the src blocks cause the numbering to reset, so all
> items in a sequence like this are numbered 1
This patch fixes this issue - but I cannot say anymore why the code in
org-export-html-close-lists-maybe does in fact work. The code looks
wrong, but it seems to work. What looks wrong is that i does not
check for the true indentation in the case when the line is not
protected. It must be that this case is covered by some other code
further down in the exporter.
* contrib/lisp/org-special-blocks.el (org-special-blocks-make-special-cookies):
Emacs 22 doesn't have string-match-p
* lisp/org-freemind.el (org-freemind-write-mm-buffer):
(org-freemind-get-node-style):
Emacs 22 doesn't have string-match-p
* lisp/org-html.el (org-html-make-link):
Use new org-string-match-p for compatibility
Patch by Stephen Peters.
Stephen writes:
> When creating a table, I was noticing that the
> <colgroup><col>... provides useful alignment information based on
> whether or not the column has numbers in it. I think, however, that
> there is a mistake in this routine. Take, for example, the following
> table:
>
> | Id | Task | Developer | Estimate | Spent | Remaining | Comp.% | Updated |
> |-----+--------------+-----------+----------+-------+-----------+--------+-----------------|
> | 1 | Task One | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 2 | Task Two | SLP | 1 | 0 | 1 | 0 | SLP, 2010-04-27 |
> | 3 | Task Three | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 4 | Task Four | SLP | 2 | 0 | 2 | 0 | SLP, 2010-04-27 |
> | 5 | Task Five | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 5.1 | Another Task | XML team | 0 | 1 | 0 | 0 | SLP, 2010-04-27 |
> | 6 | Task Six | SLP | .25 | 0 | 0.25 | 0 | SLP, 2010-04-27 |
> | 6.1 | More Tasks | DB team | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
> | 7 | Task Seven | SLP | 3 | 0 | 3 | 0 | SLP, 2010-04-27 |
>
> When the colgroup list is created for this table, it reads:
>
> <colgroup><col align="right" /><col align="left" /><col align="left" /><col align="right" /><col align="right" /><col align="left" /><col align="left" /><col align="left" />
> </colgroup>
>
> Note that the first columns are correct, but the last few are not. It
> should read right, left, left, right, right, right, right, left.
>
> I believe that this is due to the (< i nline) comparison within
> org-format-org-table-html, which is nonsensical because it's trying to
> compare a column number with a number of rows. I've attached a patch
> for the problem.
Sebastien Rose writes:
> there was much discussion about a terminator and I ran into a problem,
> that made me think we need one. But then I found we had one --- it's
> just not used on HTML export.
>
>
> Below is a little file I wrote. Thanks to the `- __' items, it results
> in the XHTML closely to what I wanted it to.
> But only as long as I use those _undocumented_ `- __' items. Once you
> remove them, you'll see, that the `#+html: </div...' stuff ends up
> inside the last list item and the XHTML will not validate.
>
>
> As I looked at it, I found the most natural solution would be, to
> terminate the list by regarding the indentation of `#+WHATEVER' and
> `#+BEGIN_WHATEVER' if inside lists [fn:1].
>
>
>
> The patch below (diffed against `remove-compatibility-code') makes
> XHTML-export honor the indentation of `#+SPECIALS'.
>
>
>
> Here's the Org-file I wrote (remove and add the `- __' list items to see
> the effect):
>
> #+OPTIONS: toc:nil
> #+STYLE: <style type="text/css">
> #+STYLE: body,p,div,td{font-size:13px;font-family:sans-serif;}
> #+STYLE: div { text-align:left; }
> #+STYLE: #content {width:550px;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: #postamble { width:550px;clear:both;border-top:1px solid black;
> #+STYLE: margin-left:auto;margin-right:auto;text-align:center; }
> #+STYLE: </style>
>
> * List of design patterns
>
> #+HTML: <div style="width:48%;float:left;">
> *Behavioural Patterns*
> - [[file:BatchCommand][BatchCommand]]
> - [[file:ChainOfResponsibility.org][Chain Of Responsibility]]
> - [[file:Command.org][Command]], UndoableCommand and BatchCommand
> - [[file:Interpreter.org][Interpreter]]
> - [[file:Iterator.org][Iterator]]
> - [[file:Mediator.org][Mediator]]
> - [[file:Memento.org][Memento]]
> - [[file:NullObject][NullObject]]
> - [[file:Observer.org][Observer]]
> - [[file:State.org][State]]
> - [[file:Strategy.org][Strategy]]
> - [[file:TemplateMethod.org][Template Method]]
> - [[file:Visitor.org][Visitor]]
> *Creational Patterns*
> - [[file:AbstractFactory.org][Abstract Factory]]
> - [[file:Builder.org][Builder]]
> - [[file:Factory.org][Factory]]
> - [[file:FactoryMethod.org][Factory Method]]
> - [[file:Prototype.org][Prototype]]
> - [[file:Singleton.org][Singleton]]
> - __
> #+html: </div>
> #+html: <div style="width:48%;float:right;">
> *Structural Patterns*
> - [[file:Adapter.org][Adapter]]
> - [[file:Composite.org][Composite]]
> - [[file::Bridge.org][Bridge]]
> - [[file:Decorator.org][Decorator]]
> - [[file:Facade.org][Facade]]
> - [[file:Flyweight.org][Flyweight]]
> - [[file:Proxy.org][Proxy]]
> *Unsorted*
> - [[file:BusinessDelegate.org][Business Delegate]]
> - [[file:DataAccessObject.org][Data Access Object]]
> - [[file:DataTransferObject.org][Data Transfer Object]]
> - [[file:DependencyInjection.org][Dependency Injection]]
> - [[file:FluentInterface.org][Fluent Interface]]
> - [[file:InversionOfControl.org][Inversion Of Control]]
> - [[file:ModelViewControler.org][Model View Controler]]
> - [[file:ModelViewPresenter.org][Model View Presenter]]
> - [[file:Plugin.org][Plugin]]
> - __
> #+HTML: </div>
Dan Davison writes:
> Bug report
> ==========
> If I have this:
>
> A [[file:zz.org::#mytarget][link]] to a target with a custom ID
>
> and export it to HTML, I get
>
> A <a href="zz.html##mytarget">link</a> to a target with a custom ID
>
> which (in firefox on linux) links to the file but does not jump to the
> target. However, if I change the '##' to '#' then firefox jumps to the
> correct location. Is this an org bug?
>
> Very tentatively proposed patch
> ===============================
> I've investigated a bit (notes below), resulting in this proposed patch:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/lisp/org-html.el b/lisp/org-html.el
> index aa70408..5ee5b19 100644
> --- a/lisp/org-html.el
> +++ b/lisp/org-html.el
> @@ -1110,7 +1110,7 @@ lang=\"%s\" xml:lang=\"%s\">
> (abs-p (file-name-absolute-p filename))
> thefile file-is-image-p search)
> (save-match-data
> - (if (string-match "::\\(.*\\)" filename)
> + (if (string-match "::#?\\(.*\\)" filename)
> (setq search (match-string 1 filename)
> filename (replace-match "" t nil filename)))
> (setq valid
> --8<---------------cut here---------------end--------------->8---
>
> Doc patch
> =========
> The link above (file:zz.org::#mytarget) was created by C-c l on a
> heading with a CUSTOM_ID property. However, I couldn't see where in the
> manual links of this form are documented. Do we need to add this link
> type to section 4.7 "Search options in file links", e.g.
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/doc/org.texi b/doc/org.texi
> index f49f056..c8cc1a5 100644
> --- a/doc/org.texi
> +++ b/doc/org.texi
> @@ -3116,6 +3116,7 @@ link, together with an explanation:
> [[file:~/code/main.c::255]]
> [[file:~/xx.org::My Target]]
> [[file:~/xx.org::*My Target]]
> +[[file:~/xx.org::#my-custom-id]]
> [[file:~/xx.org::/regexp/]]
> @end example
>
> @@ -3130,6 +3131,8 @@ link will become an HTML reference to the corresponding named anchor in
> the linked file.
> @item *My Target
> In an Org file, restrict search to headlines.
> +@item #my-custom-id
> +Link to a heading with a @code{CUSTOM_ID} property
> @item /regexp/
> Do a regular expression search for @code{regexp}. This uses the Emacs
> command @code{occur} to list all matches in a separate window. If the
> --8<---------------cut here---------------end--------------->8---
>
> Notes
> =====
> At line 1134 of org-html.el there is
>
> (setq thefile (concat thefile "#"
> (org-solidify-link-text
> (org-link-unescape search)))))
>
> during evaluation of which 'search is bound to "#mytarget", which
> suggested that the problem might be in the regexp parsing creating
> 'search.
Daniel Clemente writesL
> Hi, I found an HTML export bug with org-mode 6.34c-140-g44c8 and
> older. I used:
>
> --------------------------------------------------------
> * only one section
> #+BEGIN_EXAMPLE:
>
> We need:
> ,* pears
> ,* lettuce
> ,* watermelons
>
> Very important!
> #+END_EXAMPLE:
> --------------------------------------------------------
>
> And the outputed table of contents had this code:
>
> --------------------------------------------------------
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#sec-1">1 only one section </a></li>
> <li><a href="#sec-2">2 pears</a></li>
> <li><a href="#sec-3">3 lettuce</a></li>
> <li><a href="#sec-4">4 watermelons</a></li>
> </ul>
> </div>
> --------------------------------------------------------
>
> This is wrong because the asterisks inside the example don't
> represent headers. There should be only one header.
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
Carsten Dominik
Bastien Guerry
Daniel Clemente
Noorul Islam
Nicolas Goaziou
Manish Sharma
Philip Rooke
Bernt Hansen
Sebastian Rose
Julien Danjou
Tom Breton (Tehom)
Eric Schulte