emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Nick Dokos <nicholas.dokos@hp.com>
To: Andreas Leha <andreas.leha@med.uni-goettingen.de>, emacs-orgmode@gnu.org
Subject: Re: preview latex fragments
Date: Mon, 28 May 2012 00:56:41 -0400	[thread overview]
Message-ID: <24698.1338181001@alphaville> (raw)
In-Reply-To: Message from Nick Dokos <nicholas.dokos@hp.com> of "Thu, 24 May 2012 11:39:41 EDT." <8463.1337873981@alphaville>

Nick Dokos <nicholas.dokos@hp.com> wrote:

> Andreas Leha <andreas.leha@med.uni-goettingen.de> wrote:
> 
> ...
> > >>> I experience a problem with the preview of latex fragments:  I can not
> > >>> change the foreground color (in org-format-latex-options).  On a dark
> > >>> background, the black fragments are barely visible.
> > >>>
> > Actually, now I can again reproduce it.  The problem seems to be tikz:
> > With tikz in the latex header, foreground is always black.  So probably
> > more a LaTeX-issue?
> > 
> > ...
> >
> > Can I make the foreground changing work even with tikz loaded in the
> > latex document?
> > 
> 
> I can reproduce it too, without tikz. I have a green-on-black setup but
> I think the underlying reason (at least in my case: Andreas's case might
> be different) is minted. I'm appending an org file with my
> investigation.
> 
> Nick
>
> ... investigation elided...
>
> So either the production of the fragment is wrong or the production of
> the png from the fragment, probably the former. The latex code for the
> fragment follows. If I again do the latex/dvipng run by hand (with
> --shell-escape to accommodate minted) I get an all-black png. If I
> comment out minted, it works.
> 
> #+BEGIN_SRC latex
> \documentclass{article}
> \usepackage[usenames]{color}
> \usepackage{amsmath}
> \usepackage[mathscr]{eucal}
> \pagestyle{empty}             % do not remove
> \usepackage{minted}
> \usepackage[utf8]{inputenc}
> \usepackage[T1]{fontenc}
> % Package fixltx2e omitted
> \usepackage{graphicx}
> % Package longtable omitted
> % Package float omitted
> % Package wrapfig omitted
> \usepackage{soul}
> \usepackage{textcomp}
> \usepackage{marvosym}
> \usepackage{wasysym}
> \usepackage{latexsym}
> \usepackage{amssymb}
> % Package hyperref omitted
> \tolerance=1000
> % The settings below are copied from fullpage.sty
> \setlength{\textwidth}{\paperwidth}
> \addtolength{\textwidth}{-3cm}
> \setlength{\oddsidemargin}{1.5cm}
> \addtolength{\oddsidemargin}{-2.54cm}
> \setlength{\evensidemargin}{\oddsidemargin}
> \setlength{\textheight}{\paperheight}
> \addtolength{\textheight}{-\headheight}
> \addtolength{\textheight}{-\headsep}
> \addtolength{\textheight}{-\footskip}
> \addtolength{\textheight}{-3cm}
> \setlength{\topmargin}{1.5cm}
> \addtolength{\topmargin}{-2.54cm}
> \begin{document}
> \[
> 2 + 2 = 4
> \]
> \end{document}
> 
> #+END_SRC


I asked on comp.text.tex and Philipp Stephani provided the following
explanation (fragment2.tex is a simplified version of the above tex
file):

,----
| nick <nobody@nowhere.non> writes:
| 
| > If I process the following file through latex and dvipng:
| >
| >    latex [--shell-escape] fragment2.tex
| >    dvipng -fg "rgb 0 1 0" -bg "rgb 0 0 0" -T tight -D 140\
| >      -o fragment2.png fragment2.dvi
| >
| > I get a black blob as output if the \usepackage{minted} line
| > is included, but the expected image (a green-on-black "2 + 2 = 4"),
| > ...
| > Is this a minted bug? a dvipng bug? both? neither?
| 
| It's a feature/unavoidable technical limitation.  A more minimal example
| that doesn't even require minted is
| 
| \documentclass{article}
| \usepackage{xcolor}
| \begin{document}
| a
| \end{document}
| 
| xcolor is loaded by minted, and it explicitly initializes the foreground
| color.  According to the dvipng man page,
| 
|     -fg color_spec
|            Choose foreground color for the images. *This option will be
|            ignored if there is a foreground color \special in the DVI.*
| 
| So you should rather set the desired foreground color in the TeX file,
| that's less fragile.
| 
| -- 
| Philipp Stephani
`----

So it might be worth thinking about doing that when previewing latex
fragments. I haven't tried anything out yet, but I thought I'd post this
for any intrepid souls who might like to experiment with it.

Nick

  reply	other threads:[~2012-05-28  4:57 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-23 21:46 preview latex fragments Andreas Leha
2012-05-24  9:10 ` Bastien
2012-05-24 12:05   ` Andreas Leha
2012-05-24 12:18     ` Andreas Leha
2012-05-24 15:39       ` Nick Dokos
2012-05-28  4:56         ` Nick Dokos [this message]
2012-08-03 18:26 ` Bastien
2012-08-03 19:10   ` Andreas Leha
2012-08-06 16:36     ` darcamo

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=24698.1338181001@alphaville \
    --to=nicholas.dokos@hp.com \
    --cc=andreas.leha@med.uni-goettingen.de \
    --cc=emacs-orgmode@gnu.org \
    /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).