From: Carsten Dominik <carsten.dominik@gmail.com>
To: "Sébastien Vauban" <wxhgmqzgwmuf@spammotel.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: Re: Bugs when converting to LaTeX
Date: Fri, 6 Nov 2009 12:52:41 +0100 [thread overview]
Message-ID: <52A8F1F4-F9A6-4AA9-8EDD-2DA37428DCE6@gmail.com> (raw)
In-Reply-To: <87ws2328f9.fsf@mundaneum.com>
On Nov 6, 2009, at 12:34 PM, Sébastien Vauban wrote:
> Hi Carsten,
>
> Carsten Dominik wrote:
>> On Oct 27, 2009, at 9:47 AM, Sébastien Vauban wrote:
>>>>
>>>> Unfortunately, this is a weakness of the list parser in the LaTeX
>>>> exporter. It cannot handle this kind of post-subitem text in an
>>>> item list.
>>>> This really must be fixed, and it is on my list, but it is hard.
>>>
>>> Hopefully, this will be fixed soon, because this is quite scary.
>>> Though,
>>> that does not imply it is easy to do...
>>
>> Be my guest to give it a try.
>
> I'd be glad my level for debugging Emacs Lisp was that high.
> Unfortunately,
> not sure it is...
Hi Sebastian, this is not really an issue for debugging.
The list parser used by the LaTeX exporter simply does
not cater for text intermittent in a list, and the Lisp structure
created by the parser does not have a way to represent
such text. So this is not "a bug" you'd have to find, but rather
new code which would have to be written.....
>
> How do you do in such a case? Adding edebug calls in some
> functions? Other
> way?
yes, or (debug)
- Carsten
>
>
>>> Here a couple of other conversion bugs that I found:
>>>
>>> --8<---------------cut here---------------start------------->8---
>>> - /S'il faut remodéliser ce qui est dans le code COBOL, comment
>>> faire ?
>>> Discussions avec le business, relire le COBOL ? Chez nous, la
>>> tarification n'est pas modélisée. Pourtant, c'est là qu'il faut
>>> aller
>>> vite vis-à-vis du marché./
>>
>> You need to configure `org-emphasis-regexp-components' and increase
>> the number
>> of newlines allowed in these expressions.
>>
>>>
>>> The above "question" (in a FAQ) should be in italics. But, to do
>>> so, we
>>> have to split it in multiple chunks in italics:
>>>
>>> - /S'il faut remodéliser ce qui est dans le code COBOL, comment
>>> faire ?/
>>> /Discussions avec le business, relire le COBOL ?/ /Chez nous, la
>>> tarification n'est pas modélisée./ /Pourtant, c'est là qu'il
>>> faut aller
>>> vite vis-à-vis du marché./
>>>
>>> - Le /challenge/ : efficacité et rapidité...
>>>
>>> Here, the word challenge is not in italics because the following
>>> character is an unbreakable space (*not* a normal space).
>>
>> Maybe you can fix this by adding your unbreakable space in org-
>> emphasis-regexp-components to the end of the second string of
>> characters,
>> these are the characters allowed after an emphasis string.
>
> Done it:
>
> --8<---------------cut here---------------start------------->8---
> ;; Add the unbreakable space as allowed character after an emphasis
> ;; string, and modify the maximum number of newlines allowed in an
> ;; emphasis
> (setq org-emphasis-regexp-components
> '(" ('\"{"
> "- ., :!?;'\")}\\"
> "
> \n,\"'"
> "."
> 4))
> --8<---------------cut here---------------end--------------->8---
>
> None of the above 2 mentionned problem seems to disappear, though,
> on this
> ECM:
>
> --8<---------------cut here---------------start------------->8---
> - /S'il faut remodéliser ce qui est dans le code COBOL, comment
> faire ?
> Discussions avec le business, relire le COBOL ? Chez nous, la
> vite vis-à-vis du marché./
>
> The above "question" (in a FAQ) should be in italics. But, to do
> so, we
> have to split it in multiple chunks in italics:
>
> - /S'il faut remodéliser ce qui est dans le code COBOL, comment
> faire ?/
> /Discussions avec le business, relire le COBOL ?/ /Chez nous, la
> tarification n'est pas modélisée./ /Pourtant, c'est là qu'il faut
> aller
> vite vis-à-vis du marché./
>
> - Le /challenge/ : efficacité et rapidité...
>
> Here, the word challenge is not in italics because the following
> character
> is an unbreakable space (*not* a normal space).
>
> Note -- I'm forced to use such characters in order to get my
> LaTeX PDF
> correctly outputted. Anyway, under Emacs, the normal space is
> converted to an unbreakable one, each time it is before a ":"
> character, so that's easy to do, but the output is not
> correctly
> converted.
> --8<---------------cut here---------------end--------------->8---
>
>
>>> Note -- I'm forced to use such characters in order to get my
>>> LaTeX
>>> PDF correctly outputted.
>>
>> I don't understand that. Could you please elaborate?
>
> Yes. I mean: would I write pure LaTeX from scratch, I would insert
> `~' here
> and there when I want an unbreakable space to be produced (resulting
> in a nice
> PDF output).
>
> Here, as I write pure Org that gets converted, I need to insert a real
> unbreakable space in my Org source. That's the source of some
> problems, such
> as the second above mentionned (emphasis not correct after word
> "challenge").
>
> Note -- Currently, that character is not converted to a tilde when
> exporting to LaTeX. That could be a good option, though.
>
> Best regards,
> Seb
>
> --
> Sébastien Vauban
>
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Remember: use `Reply All' to send replies to the list.
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
- Carsten
next prev parent reply other threads:[~2009-11-06 11:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-26 15:46 Bugs when converting to LaTeX Sébastien Vauban
2009-10-26 19:17 ` Carsten Dominik
2009-10-27 8:47 ` Sébastien Vauban
2009-10-28 9:17 ` Carsten Dominik
2009-11-06 11:34 ` Sébastien Vauban
2009-11-06 11:52 ` Carsten Dominik [this message]
2009-11-09 8:58 ` Sébastien Vauban
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52A8F1F4-F9A6-4AA9-8EDD-2DA37428DCE6@gmail.com \
--to=carsten.dominik@gmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=wxhgmqzgwmuf@spammotel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).