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 simple
.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
na
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
>>
>&g
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 s
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
>
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 should
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 <skost...@lyx.org>:
> 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 p
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 need an "a
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
[colorlinks=true, hypertex]{hyperref}
to
\usepackage[colorlinks=true]{hyperref}
it compiles fine in PDF (XeTeX) and continues to compile with pdfTeX.
Sure. The hypertex option is only relevant for dvi based drivers (as the
definition you quoted clearly states).
Can I remove it?
Depends
gt; lib/doc/Formula-numbering.lyx
>
>>> I change
>>>
>>> \usepackage[colorlinks=true, hypertex]{hyperref}
>>> to
>>> \usepackage[colorlinks=true]{hyperref}
>>>
>>> it compiles fine in PDF (XeTeX) and continues to compile with pdfTe
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 pdfTeX.
Sure. The hypertex option
On Mon, Oct 7, 2013 at 2:04 AM, Jürgen Spitzmüller sp...@lyx.org 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}
to
\usepackage[colorlinks=true]{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
On Mon, Oct 7, 2013 at 2:04 AM, Jürgen Spitzmüller <sp...@lyx.org> 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, h
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
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
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
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 #. Thanks!
You have my
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 #.
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!
Thanks! :)
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
().useNonTeXFonts)
cs xelatex;
- // DVI output fails sometimes with hyperref
- // (probably a preview-latex/hyperref bug)
- else if (buffer_.params().pdfoptions().use_hyperref)
- cs pdflatex;
string const command = libScriptSearch(cs.str
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
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
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 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 the final word on
> 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!
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
)
+++ 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/hype
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
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
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 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
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. venom is working on a better
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 proposed
do you notice sometimes the eqn numbers are way to the right of the LyX
window, half outside the LyX window?
> 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 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 proposed
do you notice sometimes the eqn numbers are way to the right of the LyX
window, half outside the LyX window?
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 to use
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 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 have
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
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 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
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
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
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 less drawbacks
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 legacy route failed.
The patch
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 affect
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
All
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 preview
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
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
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
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 less drawbacks
> 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 legacy rou
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 affect
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
All
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 preview
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
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
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 method was used on such
snippets
> 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 dvip
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
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
. 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 ideally, the
previews
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
> 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
. 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 ideally, the
previews
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
> 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
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
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.pdfoptions().use_hyperref
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
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.pdfopt
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
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.
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
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
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
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 is the common way to avoid white space in TeX
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
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
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
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
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
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
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 is the comm
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
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
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
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 latin1
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-usersm=122506643128124w=2
1 - 100 of 470 matches
Mail list logo
