e:
>>
>> Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe <
>> ajpars...@gmail.com>:
>>
>>> LyX 2.4.0 testing, windows 10
>>>
>>> Checking Use Hyperref Support stalls display of previews on my system.
>>> I've attached two s
.4.0 testing, windows 10
Checking Use Hyperref Support stalls display of previews on
my system.
I've attached two simple documents showing the effect. In
2.3.5.2 the
formation of previews is not stalled, but it is slowed. My
(no doubt
naive
Am Di., 3. Nov. 2020 um 20:33 Uhr schrieb Andrew Parsloe <
ajpars...@gmail.com>:
>
> On 4/11/2020 7:03 am, Yu Jin wrote:
>
> Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe <
> ajpars...@gmail.com>:
>
>> LyX 2.4.0 testing, windows 10
>>
>>
On 4/11/2020 7:03 am, Yu Jin wrote:
Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe
mailto:ajpars...@gmail.com>>:
LyX 2.4.0 testing, windows 10
Checking Use Hyperref Support stalls display of previews on my
system.
I've attached two simple documents
Am So., 1. Nov. 2020 um 21:54 Uhr schrieb Andrew Parsloe <
ajpars...@gmail.com>:
> LyX 2.4.0 testing, windows 10
>
> Checking Use Hyperref Support stalls display of previews on my system.
> I've attached two simple documents showing the effect. In 2.3.5.2 the
> fo
LyX 2.4.0 testing, windows 10
Checking Use Hyperref Support stalls display of previews on my system.
I've attached two simple documents showing the effect. In 2.3.5.2 the
formation of previews is not stalled, but it is slowed. My (no doubt
naive ) notion is that hyperref and preview s
On 2018-09-13 13:15, Daniel wrote:
Changing
Document > Settings > PDF Properties > Bookmarks > Level
seems to have no effect (in output and code). I guess this is a bug and
it should set the hyperref option
bookmarksdepth=
I filed it as a bug: https://www.lyx.org/trac/ticket/11289
Daniel
Changing
Document > Settings > PDF Properties > Bookmarks > Level
seems to have no effect (in output and code). I guess this is a bug and
it should set the hyperref option
bookmarksdepth=
Daniel
2016-11-23 18:05 GMT+01:00 Scott Kostyshak :
> If there is a hyperlink inset, LyX seems to use hyperref regardless of
> whether "use hyperref support" is checked in document settings. I was
> initially surprised by this (I did not know that the particular document
>
On Thu, Nov 24, 2016 at 10:57:03AM +, Guenter Milde wrote:
> I don't think hyperref should be loaded if the setting says "no".
True, but the setting doesn't say "no". It just doesn't say "yes". But
it is clearly confusing.
> Maybe we
On 2016-11-23, Scott Kostyshak wrote:
> If there is a hyperlink inset, LyX seems to use hyperref regardless of
> whether "use hyperref support" is checked in document settings. I was
> initially surprised by this (I did not know that the particular document
> used hyperlink
If there is a hyperlink inset, LyX seems to use hyperref regardless of
whether "use hyperref support" is checked in document settings. I was
initially surprised by this (I did not know that the particular document
used hyperlink insets), although when I realized that hyperlink insets
wer
>> I change
>>>
>>> \usepackage[colorlinks=true, hypertex]{hyperref}
>>> to
>>> \usepackage[colorlinks=true]{hyperref}
>>>
>>> it compiles fine in PDF (XeTeX) and continues to compile with pdfTeX.
>>
>> Sure. The hypertex opti
On Mon, Oct 7, 2013 at 2:04 AM, Jürgen Spitzmüller wrote:
> Scott Kostyshak wrote:
>> If in the LaTeX preamble
>
> Which document are you talking about?
lib/doc/Formula-numbering.lyx
>> I change
>>
>> \usepackage[colorlinks=true, hypertex]{hyperref}
>
Scott Kostyshak wrote:
> If in the LaTeX preamble
Which document are you talking about?
> I change
>
> \usepackage[colorlinks=true, hypertex]{hyperref}
> to
> \usepackage[colorlinks=true]{hyperref}
>
> it compiles fine in PDF (XeTeX) and continues to compile with pdf
If in the LaTeX preamble I change
\usepackage[colorlinks=true, hypertex]{hyperref}
to
\usepackage[colorlinks=true]{hyperref}
it compiles fine in PDF (XeTeX) and continues to compile with pdfTeX.
I do not notice any change in the output when viewing with Evince and
Okular.
According to the
I am unable to get preview images for the file attached to bug #8340
unless I disable hyperref support. The error is
l.230 --- TeX4ht warning --- \usepackage[...]{hyperref} assumes `pdf'
option, n
ot `tex4ht' ---
! LaTeX Error: Command \Hy@SectionHShift already defined.
Enrico Forestieri wrote:
> On Fri, Apr 01, 2011 at 12:17:43AM +0200, Pavel Sanda wrote:
>
> > Julien Rioux wrote:
> > > On 31/03/2011 3:36 AM, venom00 wrote:
> > >> Feel free to edit the patch if something is wrong. Just when (and if)
> > >> you
> > >> commit
> > >> tell me the revision #. Thank
On Fri, Apr 01, 2011 at 12:17:43AM +0200, Pavel Sanda wrote:
> Julien Rioux wrote:
> > On 31/03/2011 3:36 AM, venom00 wrote:
> >> Feel free to edit the patch if something is wrong. Just when (and if) you
> >> commit
> >> tell me the revision #. Thanks!
> >
> > You have my OK and Pavel can have th
Julien Rioux wrote:
> On 31/03/2011 3:36 AM, venom00 wrote:
>> Feel free to edit the patch if something is wrong. Just when (and if) you
>> commit
>> tell me the revision #. Thanks!
>
> You have my OK and Pavel can have the final word on it.
i really didnt follow this thread closely to make some
On 31/03/2011 3:36 AM, venom00 wrote:
Feel free to edit the patch if something is wrong. Just when (and if) you commit
tell me the revision #. Thanks!
You have my OK and Pavel can have the final word on it.
--
Julien
On 31/03/2011 3:36 AM, venom00 wrote:
Do they remain there or after moving the mouse/cursor they go to the right
place? I've noticed similar problems with IP images: when they're rendered for
the first time often are in the wrong place, but moving the cursor over it
solves the problem (a simple r
38163)
+++ src/graphics/PreviewLoader.cpp (copia locale)
@@ -605,10 +605,6 @@
// FIXME what about LuaTeX?
if (buffer_.params().useNonTeXFonts)
cs << " xelatex";
- // DVI output fails sometimes with hyperref
- // (probably a preview-latex
On Thu, Mar 31, 2011 at 12:40:12AM +0200, veno...@arcadiaclub.com wrote:
[...]
> Index: lib/scripts/lyxpreview2bitmap.py
> ===
> --- lib/scripts/lyxpreview2bitmap.py (revisione 38163)
> +++ lib/scripts/lyxpreview2bitmap.py (copia loc
> That's great, thanks! The patch applies fine and I can't make
> it to fail
> with my test cases. I get a bunch of
>
> GPL Ghostscript 8.71: Unrecoverable error, exit code 1
>
> on the terminal but all previews appear (and I think I saw
> those error
> messages before, too). Nice work!
Than
do you notice sometimes the eqn numbers are way to the right of the LyX
window, half outside the LyX window?
On 30/03/2011 6:40 PM, veno...@arcadiaclub.com wrote:
From what I can tell the issue arises from a bug in either hyperref
package or preview-latex package: when eqn numbers are
involved an error
occurs on dvi output and we don't recover a preview image. As
mentioned
the solutions propose
> From what I can tell the issue arises from a bug in either hyperref
> package or preview-latex package: when eqn numbers are
> involved an error
> occurs on dvi output and we don't recover a preview image. As
> mentioned
> the solutions proposed are workarounds
On 03/29/2011 09:29 AM, Julien Rioux wrote:
On 29/03/2011 2:46 AM, Guenter Milde wrote:
However, is it possible to use "non-image" equation numbers also with
"math images"? Seems like the better method anyway.
Günter
Everything's possible. Seems to me the better method too. Please can
we h
On 29/03/2011 2:46 AM, Guenter Milde wrote:
However, is it possible to use "non-image" equation numbers also with
"math images"? Seems like the better method anyway.
Günter
Everything's possible. Seems to me the better method too. Please can we
have other opinions on this?
--
Julien
On 2011-03-28, Julien Rioux wrote:
> On 27/03/2011 7:09 PM, Pavel Sanda wrote:
>> Julien Rioux wrote:
>>> I would suggest one more:
>>> - remove eqn. numbers from previews; they tend to be wrong anyway
>> does not this break xhtml math export with images?
> yes, it would.
However, is it possible
On 28/03/2011 4:45 PM, Richard Heck wrote:
I see, so we'd have to regenerate these quite often. So perhaps removing
the numbers is the right way to go, anyway.
In 1.6, if I remember right, one always just gets (1) as the equation
number, which is also kind of useless. But it does at least indica
On 03/28/2011 04:12 PM, Julien Rioux wrote:
On 28/03/2011 3:57 PM, Richard Heck wrote:
On 03/28/2011 01:24 PM, Julien Rioux wrote:
At the moment it's working fine. We have three workaround solutions
for the dvi/eqn. numbers/hyperref/preview bug
#1 go pdf route
#2 remove hyperref from pr
On 28/03/2011 3:57 PM, Richard Heck wrote:
On 03/28/2011 01:24 PM, Julien Rioux wrote:
At the moment it's working fine. We have three workaround solutions
for the dvi/eqn. numbers/hyperref/preview bug
#1 go pdf route
#2 remove hyperref from preview
#3 remove eqn. numbers from previews
On 03/28/2011 01:24 PM, Julien Rioux wrote:
At the moment it's working fine. We have three workaround solutions
for the dvi/eqn. numbers/hyperref/preview bug
#1 go pdf route
#2 remove hyperref from preview
#3 remove eqn. numbers from previews
All three have problems, and #3 would a
> At the moment it's working fine. We have three workaround
> solutions for
> the dvi/eqn. numbers/hyperref/preview bug
>
> #1 go pdf route
> #2 remove hyperref from preview
> #3 remove eqn. numbers from previews
#4 use pdflatex as a fallback solution after the legac
hree workaround solutions for
the dvi/eqn. numbers/hyperref/preview bug
#1 go pdf route
#2 remove hyperref from preview
#3 remove eqn. numbers from previews
All three have problems, and #3 would affect xhtml image export. At the
moment #1 has been applied and still seems the solution with
On 03/28/2011 01:05 PM, Julien Rioux wrote:
On 27/03/2011 7:09 PM, Pavel Sanda wrote:
Julien Rioux wrote:
I would suggest one more:
- remove eqn. numbers from previews; they tend to be wrong anyway
does not this break xhtml math export with images?
pavel
yes, it would.
In that case, what
On 27/03/2011 7:09 PM, Pavel Sanda wrote:
Julien Rioux wrote:
I would suggest one more:
- remove eqn. numbers from previews; they tend to be wrong anyway
does not this break xhtml math export with images?
pavel
yes, it would.
--
Julien
Julien Rioux wrote:
> I would suggest one more:
> - remove eqn. numbers from previews; they tend to be wrong anyway
does not this break xhtml math export with images?
pavel
> Right. See this example file and revert r37696 locally. The
> bug appear
> because with hyperref activated, psspecials appear and we send the
> numbered equations snippets to legacy method. The legacy
> method doesn't
> handle them well. Previously, the dvipng
's too specific. The bug report is specific: combine
eqn. numbers/hyperref/preview/dvi. Remove any component to remove the
bug. But it might be too radical a solution.
Yet these are just workarounds. I try to catch attention of other
developers on how best to tackle this. It seems that i
> I would suggest one more:
> - remove eqn. numbers from previews; they tend to be wrong anyway
Isn't this too specific as a solution? I think there are several other things
wrong we'll probably never know.
> Yet these are just workarounds. I try to catch attention of other
> developers on how
http://www.lyx.org/trac/ticket/7303
There are problems with a combination of
dvi/instant-preview/hyperref/eqn numbers. Already the bug has been fixed
by going the pdf route for instant preview, but this breaks recent work
to have instant-preview of pstricks.
So far we have only workaround
> you are looking for somthing like BufferParams.pdfoptions().use_hyperref,
Yes, thanks.
I used this to fix http://www.lyx.org/trac/ticket/6470.
regards Uwe
Uwe Stöhr wrote:
> I'm looking for a way to check in InsetBibtex.ccp in InsetBibtex::latex
> that the user has checked the "use hyperref" checkbox in the PDF section of
> the document settings. How can this be done?
you are looking for somthing like BufferParams.pdfopti
I'm looking for a way to check in InsetBibtex.ccp in InsetBibtex::latex that the user has checked
the "use hyperref" checkbox in the PDF section of the document settings. How can this be done?
thanks and regards
Uwe
Richard Heck wrote:
> It's not that I don't agree. But we chop lines in weird ways in other
> places to try to stay below the 80-character limit. I was assuming this
> issue was for the same reason. Perhaps not.
no, these are intentional eolns so that tex output is readable by
human eyes.
pavel
On 05/25/2010 08:13 PM, Uwe Stöhr wrote:
Am 25.05.2010 22:41, schrieb Richard Heck:
I think people would be happy to do *something*, but Uwe was not happy
with the proposal you made. My own view, for what it is worth, is that
the worry about line length is a bit quaint, since most editors nowad
Am 25.05.2010 22:41, schrieb Richard Heck:
I think people would be happy to do *something*, but Uwe was not happy
with the proposal you made. My own view, for what it is worth, is that
the worry about line length is a bit quaint, since most editors nowadays
"soft wrap" anyway. But other people f
Am 25.05.2010 22:27, schrieb travis+w-lyx@subspacefield.org:
If I understand things correctly, it sounds like tth has a slightly
simplistic parser for LaTeX that doesn't handle this very well,
That is the point. TTH claims to be a TeX to HTML converter. It should therefore be able to handl
Julien Rioux wrote:
> Tth's use of white space to treat unknown commands is akin to a syntax
> extension. We'll consider that a Tth feature.
>
> I guess LyX could output a comment symbol at wrapping locations, such as:
>
> \usepackage%
> {hyperref}
>
> This i
s LyX could output a comment symbol at wrapping locations, such as:
\usepackage%
{hyperref}
This is the common way to avoid white space in TeX commands. If Tth
still doesn't cope with that, consider it a Tth bug.
Regards,
Julien
On 05/25/2010 04:27 PM, travis+w-lyx@subspacefield.org wrote:
On Tue, May 25, 2010 at 12:16:08PM -, LyX Ticket Tracker wrote:
We cannot simply remove the whitespace as you proposed because this would
annoy other users, especially for example when you export the LyX file to
LaTe
On Tue, May 25, 2010 at 12:16:08PM -, LyX Ticket Tracker wrote:
> We cannot simply remove the whitespace as you proposed because this would
> annoy other users, especially for example when you export the LyX file to
> LaTeX (this is the most common export case).
However, it would still be v
Jürgen Spitzmüller wrote:
> Note that I'm not sure if this is what Nikos reported
After reading the original report [1], I'm now sure it is.
Jürgen
[1] http://marc.info/?l=lyx-users&m=122506643128124&w=2
While investigating in Nikos' report about problems with Greek hyperref
settings I noticed that we get an iconv conversion error currently if the
hypersetup data consists of glyphs that exceed the current encoding (for ex.,
the author name Νίκος Αλεξανδρής in an English document with l
Manoj Rajagopalan wrote:
> Is this a bug or a known feature?
bug
pavel
Hi developers,
I am using LyX 2.0.0svn and am up to date with the source. I have enabled
hyperref in PDF options. When I press Ctrl-D to generate DVI preview, I only
see the top left bit of each page being generated (all pages are generated).
The PDF is generated properly. Now, when I
Guenter Milde wrote:
> How would the editable preamble solve the problem that LyX does not
> know whether hyperref
> > was enabled in prefs by the users choice or by automatical proces
> ?
it wouldn't. it was just comment on the parallel bug about preamble being
discussed in trac.
pavel
On 2009-11-02, Pavel Sanda wrote:
> Waluyo Adi Siswanto wrote:
>> Dear LyX developers
>> When I use hyperlink,
>> LyX automatically loading hyperref package, and writes in the source
>> file (seen from view source), but the hyperref ui (Document>Settings)
>> d
Waluyo Adi Siswanto wrote:
> Dear LyX developers
>
> When I use hyperlink,
> LyX automatically loading hyperref package, and writes in the source
> file (seen from view source), but the hyperref ui (Document>Settings)
> does not show it has been loaded? not active.
if user
Dear LyX developers
When I use hyperlink,
LyX automatically loading hyperref package, and writes in the source
file (seen from view source), but the hyperref ui (Document>Settings)
does not show it has been loaded? not active.
I am suggesting, loading hyperref is also indicated in the UI
Bug #5941
http://www.lyx.org/trac/ticket/5941
On May 11, 2009, at 1:24 PM, Pavel Sanda wrote:
Jürgen Spitzmüller wrote:
James C. Sutherland wrote:
I think I found a LyX bug. LyX 1.6.2, Mac OSX 10.5.6
1. Create a parent document and turn off hyperref support (Document-
Settings->
Jürgen Spitzmüller wrote:
> James C. Sutherland wrote:
> > I think I found a LyX bug. LyX 1.6.2, Mac OSX 10.5.6
> >
> > 1. Create a parent document and turn off hyperref support (Document-
> > >Settings->PDF Properties, deselct hyperref)
> > 2. Create
Uwe Stöhr wrote:
> > I just tried to use beamer. I checked pdf properties/use hyperref
> > support
> > and selected no other options. I get:
> >
> > ! Undefined control sequence.
> > l.10 \hypersetup
> >{unicode=true, pdfusetitle,
> I just tried to use beamer. I checked pdf properties/use hyperref support
> and selected no other options. I get:
>
> ! Undefined control sequence.
> l.10 \hypersetup
>{unicode=true, pdfusetitle,
I cannot reproduce this. Do you have a _small_ ex
I just tried to use beamer. I checked pdf properties/use hyperref support
and selected no other options. I get:
! Undefined control sequence.
l.10 \hypersetup
{unicode=true, pdfusetitle,
> i think the code is still wrong:
>
> if both \pdf_pagebackref true & \pdf_backref true are set then you put two
> different \pdf_backref into lyx file.
I also fixed this case now.
thanks and regards
Uwe
Uwe Stöhr wrote:
> We cannot do it correctly, but at least that it looks the same in the
> output and this is a must have.
i have said from the very begining we have different views :)
> > i commited the current version and will review lyx2lyx part you commit
> later.
>
> I've put it in. I test
>> The opposite direction also
>> works, as then nothing is done,
>
> which is the culprit of the problem. normal user won't note that info
> disapeared into preamble and will look inot document settings. he will
> even try to switch hyperref again
> and i ju
info
disapeared into
preamble and will look inot document settings. he will even try to switch
hyperref again
and i just imagine what will happen then...
> For converting you are right, I missed to convert backref=true to
> backref=section. So please commit the patch you attached and I&#x
> the conversion 1.5 -> 1.6 doesn't work wrt hyperref and it will be almost
> impossible to get it right, which was one of the three reasons i objected the
> whole idea of 1.6 -> 1.5 conversion. any user of 1.6 pdfsupport who will
exchange
> docs between 1.6 and 1.5 is bou
aloss.
>
> > to me hyperref support is a new feature and there is no correct way how
> to
> > put it back into 1.5.
>
> But this already works.
nope.
the conversion 1.5 -> 1.6 doesn't work wrt hyperref and it will be almost
impossible to get it right, which was one
Uwe Stöhr wrote:
> - the option "backref" is the same as "backref=section" so we shouldn't
> provide an "On" option as this only leads to confusion
if this is true we can simplify it even more, because this line become
useless
> + string tmp = backref == "true" ? "" : "=" + backref;
> Attac
There are 3 issues in your patch:
According to
ftp://ftp.fu-berlin.de/tex/CTAN/macros/latex/contrib/hyperref/backref.pdf
- the option is "page", not "pages" (my fault)
- the option "backref" is the same as "backref=section" so we shouldn't provide an
[i]
>> +
>>
>>
> Is it possible to convert between pageref and pagebackref? Or is this just
> lost data?
to me hyperref support is a new feature and there is no correct way how to
put it back into 1.5. i know Uwe has different opinion about this so if he
or anybody else wants feel free to change it :)
> This looks fine to me, if we're sure about the LaTeX part.
of course i wait for nod from Uwe.
pavel
Pavel Sanda wrote:
+def revert_backref_options(document):
+' Remove pageref additional options '
+i = find_token(document.header, "\\pdf_pageref", 0)
+if i != -1:
+del document.header[i]
+
+
+def convert_backref_options(document):
+' We have lost pagebackref option in favo
hi,
towards bug http://bugzilla.lyx.org/show_bug.cgi?id=5340
to sum up: hyperref manual incorrectly states, that \backref is boolean
while in fact its string with false/section/pages/slides args.
this way our tex output \backref=true won't work.
we need to support these plus "pages&quo
, not only with
hyperref.
Personally, I would prefer that.
I've don that and left the string conversion as they were:
http://www.lyx.org/trac/changeset/26627
regards Uwe
Jean-Marc Lasgouttes wrote:
> > But why do we use it then for babel? The babel code (language names)
> > also contains only ASCII characters?
>
> It is probably an oversight.
right. As I wrote, there may be occurences of from_utf8 where from_ascii is
sufficient. But think carefully. Sometimes asc
Uwe Stöhr <[EMAIL PROTECTED]> writes:
>> The reason for the two calls is that from_utf8 is rather expensive, so we use
>> the much faster from_ascii whereever possible. As soon as a non-ascii
>> character is expected, we have to use from_utf8.
>
> But why do we use it then for babel? The babel cod
> The reason for the two calls is that from_utf8 is rather expensive, so we use
> the much faster from_ascii whereever possible. As soon as a non-ascii
> character is expected, we have to use from_utf8.
But why do we use it then for babel? The babel code (language names) also contains only ASCII
dn't harm to
> load color always before babel, as this problem could also occur with
> other packages that users might load in the preamble, not only with
> hyperref.
Personally, I would prefer that.
JMarc
babel, as this problem could also
occur with other packages that users might load in the preamble, not only with hyperref.
regards Uwe
Uwe Stöhr <[EMAIL PROTECTED]> writes:
> When using hyperref with the option colorlinks (that we support),
> hyperref loads the color package \AtBeginDocument. But babel loads it
> too \AtBeginDocument, so that is not loaded when babel defined
> shorthand characters. Thus
Uwe Stöhr wrote:
> Do you prefer from_ascii for all calls?
No, I prefer from_ascii for all calls where we are sure that no characters
beyond the ascii range are involved.
The reason for the two calls is that from_utf8 is rather expensive, so we use
the much faster from_ascii whereever possible.
ms.cpp
===
--- src/BufferParams.cpp (revision 26594)
+++ src/BufferParams.cpp (working copy)
@@ -917,8 +917,14 @@
}
}
- if (pdfoptions().use_hyperref)
+ if (pdfoptions().use_hyperref) {
features.require("hyperref");
+ // due to interferences with babel and hyperref, the c
Uwe Stöhr wrote:
> The attached patch implements this. To be able to do that, I needed to
> handle the color packages [x]color and pdfcolmk in a separate routine in
> LaTeXParams.cpp.
Is the from_ascii -> from_utf8 change necessary?
Jürgen
When using hyperref with the option colorlinks (that we support), hyperref
loads the color package
\AtBeginDocument. But babel loads it too \AtBeginDocument, so that is not
loaded when babel defined
shorthand characters.
Thus document with the languages Esperanto, Slovak, and some others are
Jürgen Spitzmüller wrote:
> > Are there really classes/packages that force the driver?
>
> Dunno. I've seen many things I couldn't imagine before ...
here's an example:
http://ftp.ktug.or.kr/tex-archive/macros/latex/contrib/conferences/confproc/confproc.cls
Jürgen
Jean-Marc Lasgouttes wrote:
> > We cannot always guess this. It's not unlikely that some class or package
> > loads hyperref with the pdftex driver, or something similar, and neither
> > the user nor we are informed about that.
>
> Are there really classes/packages
ight code path for previews.
>> Indeed, it does not make sense to use dvi previews when all the user
>> wants to do is use pdflatex all the time.
>
> We cannot always guess this. It's not unlikely that some class or package
> loads hyperref with the pdftex driver, or something
ot make sense to use dvi previews when all the user
> > wants to do is use pdflatex all the time.
>
> We cannot always guess this. It's not unlikely that some class or package
> loads hyperref with the pdftex driver, or something similar, and neither
> the user nor we are informed abo
reviews when all the user
> wants to do is use pdflatex all the time.
We cannot always guess this. It's not unlikely that some class or package
loads hyperref with the pdftex driver, or something similar, and neither the
user nor we are informed about that.
Anyway, my patch would also b
cases, people entered the command themselves. I think it does not
> happen with our builtin hyperref support, since we care for the correct
> driver.
>
> We could certainly say that this is a user problem, however, the extension
> does not harm. And it has the extra bonus that png
r builtin hyperref support, since we care for the correct
driver.
We could certainly say that this is a user problem, however, the extension
does not harm. And it has the extra bonus that png output is now also
supported if dvipng is not installed.
Jürgen
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jean-Marc Lasgouttes wrote:
>> I have just read the bug report but I am not sure what the actual bug
>> is. Could you summarize for me?
>
> Yes. When \usepackage[pdftex]{hyperref} is used, then hyperref's
> pdfte
Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
> Jürgen Spitzmüller wrote:
>> > If \usepackage[pdftex]{hyperref} is in the preamble, then Instant
>> > Preview doesn't work. Look at the attached example. I use LyX 1.6beta3
>> > with MiKTeX 2.7.2988
On Wed, Jul 02, 2008 at 10:27:40AM +0200, Jürgen Spitzmüller wrote:
> os << "\n"
> -<< "\\usepackage[active,delayed,dvips,showlabels,lyx]{preview}\n"
> +<< "\\ifx\\pdfoutput\\undefined\n"
> +<< " \\usepackage[active,delayed,dvips,showlabels,lyx]{preview}\n"
> +
1 - 100 of 243 matches
Mail list logo
