On Sun, Jun 9, 2024 at 1:35 PM Udicoudco wrote:
>
>
> On Sun, Jun 9, 2024 at 11:09 AM Udicoudco wrote:
>
>> Is there any particular reason why preview use dvi mode when the document
>> is configured
>> to use pdfmode with pdftex? For example, the attached compiles fine but
>> the preview fails
>
On Sun, Jun 9, 2024 at 11:09 AM Udicoudco wrote:
> Is there any particular reason why preview use dvi mode when the document
> is configured
> to use pdfmode with pdftex? For example, the attached compiles fine but
> the preview fails
>
Actually it looks like this situation was already thought o
Is there any particular reason why preview use dvi mode when the document
is configured
to use pdfmode with pdftex? For example, the attached compiles fine but the
preview fails
Udi
newfile1.lyx
Description: application/lyx
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/
lyx -e xhtml Math.lyx
>
> I notice that pdflatex is run, I think via lyxpreview2bitmap.py.
>
> Is this supposed to happen?
It will depend upon what kinds of processes are needed for maths,
etc.
In that document, some of them probably have to be exported as
image
> > de Math.lyx, when I do:
> > >
> > > lyx -e xhtml Math.lyx
> > >
> > > I notice that pdflatex is run, I think via lyxpreview2bitmap.py.
> > >
> > > Is this supposed to happen?
> >
> > It will depend upon what kinds of processes a
On Wed, 23 Nov 2022 at 04:08, Richard Kimberly Heck
wrote:
> On 11/20/22 10:22, Scott Kostyshak wrote:
> > When testing a (seemingly) different issue that Thibaut reported about
> > de Math.lyx, when I do:
> >
> >lyx -e xhtml Math.lyx
> >
> > I n
On 11/20/22 10:22, Scott Kostyshak wrote:
When testing a (seemingly) different issue that Thibaut reported about
de Math.lyx, when I do:
lyx -e xhtml Math.lyx
I notice that pdflatex is run, I think via lyxpreview2bitmap.py.
Is this supposed to happen?
It will depend upon what kinds of
When testing a (seemingly) different issue that Thibaut reported about
de Math.lyx, when I do:
lyx -e xhtml Math.lyx
I notice that pdflatex is run, I think via lyxpreview2bitmap.py.
Is this supposed to happen?
Scott
signature.asc
Description: PGP signature
--
lyx-devel mailing list
lyx
Why not LuaLaTeX?
Which seems to be where the world is going now?
PDFLaTeX is of course faster.
el
On 11/10/2022 22:35, Kornel Benko wrote:
> Am Tue, 11 Oct 2022 21:17:28 +0200 schrieb Enrico Forestieri :
>> On Tue, Oct 11, 2022 at 03:08:20PM +0200, Kornel Benko wrote:
>>>
&g
error is presumably in latex (TL2022) output. Maybe the dvi-output of latex
has not
too much attention anymore.
Apropos, in ticket 9371, the default is first proposed to pdflatex too.
Anyway, we suffer now for months from this behaviour.
Kornel
pgpZLcv24ixJS.pgp
Description: Digitale Signatur von OpenPGP
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On Tue, Oct 11, 2022 at 03:08:20PM +0200, Kornel Benko wrote:
As it is now, we have 'latex' as default for our previews. But at least
opening UserGuide.lyx fails because
1.) call to dvipdf coredumpts
2.) calls to epstopdf fail (because underlined 'gs' coredumpts)
The reason is probably that th
specify a specific
// output format (see bug 9371).
Flavor flavor = docformat
? buffer_.params().getOutputFlavor()
- : Flavor::LaTeX;
+ : Flavor::PdfLaTeX;
if (buffer_.params().encoding().package() == Encoding::japanese) {
latexparam = " --latex=platex";
flavo
On Wed, Jun 19, 2019 at 08:03:40PM +0200, mn wrote:
> The UserGuide on macOS produces in its default state just blank output.
Feel lucky that you can compile user guide at all :)
It fails here for couple reasons:
- package babel error 'french' (already reported)
- latex error: file footnotehyper.s
The UserGuide on macOS produces in its default state just blank output.
That is
- on macOS 10.12
- with LyX 2.3.3 and 2.3.2
- with TeXLive 2019
- with pdfLatex
- in all PDFKit viewers (like Preview.app, Skim) and PDFExpert
curiously:
- it did work with export per ps2pdf
- it did work with
On 08/21/2016 05:13 AM, Jean-Jacques Girardot wrote:
> Hi !
>
> I just got a bug while working on a lyx document.
> The bug is most likely in « pdflatex », and more specifically in a «
> tikzpicture ».
> This is the latex code, I forgot a « ; » after node {A} and pdflatex wen
Hi again !
Sorry, I clicked on the wrong icon.
Here is the LyX document with the tikZ bug.
Bug_pdflatex.lyx
Description: Binary data
Here is the pdflatex version used :
$ pdflatex --version
pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013)
kpathsea version 6.1.1
Copyright 2013 Peter
Hi !
I just got a bug while working on a lyx document.
The bug is most likely in « pdflatex », and more specifically in a «
tikzpicture ».
This is the latex code, I forgot a « ; » after node {A} and pdflatex went in a
infinite loop,
possibly creating a large log file.
\begin{center}\begin
Am Dienstag, 15. Dezember 2015 um 06:30:22, schrieb Guenter Milde
> On 2015-12-14, Kornel Benko wrote:
>
> > [-- Type: text/plain, Encoding: 7bit --]
>
> > Am Montag, 14. Dezember 2015 um 11:25:01, schrieb Kornel Benko
> >
> >> > > I meant the test suite is setting ascii for xetex + tex font.
On 2015-12-14, Kornel Benko wrote:
> [-- Type: text/plain, Encoding: 7bit --]
> Am Montag, 14. Dezember 2015 um 11:25:01, schrieb Kornel Benko
>
>> > > I meant the test suite is setting ascii for xetex + tex font.
>> >
>> > This is superfluous since LyX does it, too (since my fix to #9740).
>>
tings) we can distinguish
between important and less important tests.
We have the routes:
lyx -> latex¹
lyx -> latex¹ -> dvi
lyx -> latex¹ -> dvi -> ps
lyx -> latex¹ -> dvi -> ps -> pdf3
lyx -> latex¹ -> dvi -> ps -> text2
lyx -> latex¹ -> dvi -&g
Am Montag, 14. Dezember 2015 um 11:25:01, schrieb Kornel Benko
> > > I meant the test suite is setting ascii for xetex + tex font.
> >
> > This is superfluous since LyX does it, too (since my fix to #9740).
> > So this fix was not tested due to "massaging" in the test machinery and
> > there may
56aea128542205b1d31bc5df799f710d9544
> >> Author: Günter Milde
> >> Date: Wed Dec 9 08:54:38 2015 +0100
>
> >> Set default output for "complex" manuals to PDF (pdflatex).
>
> >> This is the "design format" for the man
4:38 2015 +0100
>> Set default output for "complex" manuals to PDF (pdflatex).
>> This is the "design format" for the manuals. Some features do not
>> work in other formats.
>> See http://permalink.gmane.org/gmane.editors.lyx.devel/158616
Am Montag, 14. Dezember 2015 um 08:45:19, schrieb Guenter Milde
> On 2015-12-13, Kornel Benko wrote:
>
> > [-- Type: text/plain, Encoding: quoted-printable --]
>
> > Am Sonntag, 13. Dezember 2015 um 22:25:34, schrieb Guenter Milde
> >
> >> On 2015-12-13, Kornel Benko wrote:
> >> > Am Samstag,
On 2015-12-13, Kornel Benko wrote:
> [-- Type: text/plain, Encoding: quoted-printable --]
> Am Sonntag, 13. Dezember 2015 um 22:25:34, schrieb Guenter Milde
>
>> On 2015-12-13, Kornel Benko wrote:
>> > Am Samstag, 12. Dezember 2015 um 22:52:13, schrieb Guenter Milde
>> >
> ...
>> >> c) con
Am Sonntag, 13. Dezember 2015 um 22:25:34, schrieb Guenter Milde
> On 2015-12-13, Kornel Benko wrote:
> > Am Samstag, 12. Dezember 2015 um 22:52:13, schrieb Guenter Milde
> >
>
...
> >> c) consider excluding more output formats based on BufferParams, e.g.
>
> >>* pdf[245] and dvi3 if th
On 2015-12-13, Kornel Benko wrote:
> Am Samstag, 12. Dezember 2015 um 22:52:13, schrieb Guenter Milde
>
...
>> Before the recent changes (at 3a7ec39a790/lyxgit 2015-12-09) there were
>> just 4 instances of \default_output_format pdf2:
>> (|es|de|fr|ja)/Math.lyx
> True, that was done _after_ i
On 2015-12-13, Kornel Benko wrote:
> [-- Type: text/plain, Encoding: 7bit --]
> Am Sonntag, 13. Dezember 2015 um 10:22:04, schrieb Kornel Benko
>
>> > However, regarding the docs, the test suite could treat "pdf2" just like
>> > "default".
>> Yes, we could do it.
> Done at 3ed174c
Thanks.
Am Sonntag, 13. Dezember 2015 um 10:22:04, schrieb Kornel Benko
> > However, regarding the docs, the test suite could treat "pdf2" just like
> > "default".
>
> Yes, we could do it. But the logic starts to be more and more confusing.
Done at 3ed174c
Kornel
signature.asc
Description: Thi
Am Mittwoch, 9. Dezember 2015 um 08:55:51, schrieb Günter Milde
> commit 4d0356aea128542205b1d31bc5df799f710d9544
> Author: Günter Milde
> Date: Wed Dec 9 08:54:38 2015 +0100
>
> Set default output for "complex" manuals to PDF (pdflatex).
>
> This
11. Dezember 2015 um 12:53:41, schrieb Uwe Stöhr
> >> >
>
> >> > It is not, that I am criticizing that the docs are designed for
> >> > pdflatex. (Which itself is not valid for japanese docs).
> >> > It is only the removal from the test suite.
criticizing that the docs are designed for
>> > pdflatex. (Which itself is not valid for japanese docs).
>> > It is only the removal from the test suite.
>> Problem: the "right thing" (marking the intended output format in the
>> files) had the wrong si
On 2015-12-11, Guillaume Munch wrote:
> Le 10/12/2015 09:41, Günter Milde a écrit :
>> commit 0529b40cc94a2202b14705ef40ba5ea90dc5882a
>> Author: Günter Milde
>> Date: Thu Dec 10 10:40:50 2015 +0100
>> Set default output format for manuals to PDF (pdflatex
Le 10/12/2015 09:41, Günter Milde a écrit :
commit 0529b40cc94a2202b14705ef40ba5ea90dc5882a
Author: Günter Milde
Date: Thu Dec 10 10:40:50 2015 +0100
Set default output format for manuals to PDF (pdflatex).
...
diff --git a/lib/doc/LFUNs.lyx b/lib/doc/LFUNs.lyx
index 003adf9
Am Freitag, 11. Dezember 2015 um 21:51:41, schrieb Guenter Milde
> On 2015-12-11, Kornel Benko wrote:
> > Am Freitag, 11. Dezember 2015 um 12:53:41, schrieb Uwe Stöhr
> >
>
> > It is not, that I am criticizing that the docs are designed for
> > pdflatex.
On 2015-12-11, Kornel Benko wrote:
> Am Freitag, 11. Dezember 2015 um 12:53:41, schrieb Uwe Stöhr
>
> It is not, that I am criticizing that the docs are designed for
> pdflatex. (Which itself is not valid for japanese docs).
> It is only the removal from the test suite.
Prob
eless one _can_ find some things because of such tests, which could
be done.
It is not, that I am criticizing that the docs are designed for pdflatex.
(Which itself is not
valid for japanese docs).
It is only the removal from the test suite.
> To test other things like LuaTeX etc. please
ee to create a new
folder, copy the doc files there and modify and test them as you are. If
you find there bugs we can backport changes to the docs folder after the
possible bugs in LyX have been fixed.
For now (LyX 2.2.0) the docs will only be designed for pdflatex. If
anything else fails, th
On Fri, Dec 11, 2015 at 11:46:32AM +0100, Kornel Benko wrote:
> > > It effects the test suite. Now we are there, doing exactly the same as VW.
> >
> > Could you please specify how it affects it?
>
> Sure, now only the pdf2 and lyxhtml are tested. Any possible error which
> could be found by
> l
b40cc94a2202b14705ef40ba5ea90dc5882a
> >> Author: Günter Milde
> >> Date: Thu Dec 10 10:40:50 2015 +0100
>
> >> Set default output format for manuals to PDF (pdflatex).
>
> >> Pdflatex is the recommended export tool for the manuals.
> >
0:50 2015 +0100
>> Set default output format for manuals to PDF (pdflatex).
>> Pdflatex is the recommended export tool for the manuals.
>> Pdflatex brings the best results for hyperlinking.
>> Some features (e.g. rotated text) are not available in DVI or P
Am Donnerstag, 10. Dezember 2015 um 10:41:33, schrieb Günter Milde
> commit 0529b40cc94a2202b14705ef40ba5ea90dc5882a
> Author: Günter Milde
> Date: Thu Dec 10 10:40:50 2015 +0100
>
> Set default output format for manuals to PDF (pdflatex).
>
> Pdflatex is t
Jean-Marc Lasgouttes wrote:
> 12/06/2014 13:53, Enrico Forestieri:
>> As regards LyX behaving similarly, apart this specific case (that, BTW,
>> only seems affecting LyX 2.1 and 2.2, most probably due to the gettext
>> removal, and that, BTW2, does not manifests with Qt5), I think that this
>> is
12/06/2014 13:53, Enrico Forestieri:
As regards LyX behaving similarly, apart this specific case (that, BTW,
only seems affecting LyX 2.1 and 2.2, most probably due to the gettext
removal, and that, BTW2, does not manifests with Qt5), I think that this
is already the case, as a QCoreApplication w
On Thu, Jun 12, 2014 at 11:56:03AM +0200, Jean-Marc Lasgouttes wrote:
> 11/06/2014 18:20, Enrico Forestieri:
> >>To be honest, I am not terribly well informed about this sort of
> >>topic, so I am more than happy to take your word for what is right
> >>here.
> >
> >I have checked that it is Qt itse
11/06/2014 18:20, Enrico Forestieri:
To be honest, I am not terribly well informed about this sort of
topic, so I am more than happy to take your word for what is right
here.
I have checked that it is Qt itself that calls setlocale(LC_ALL, "")
during QCoreApplication initialization. Of course,
On 06/11/2014 06:27 PM, Claudius Marpa Heine wrote:
Hi,
Please do report this as a bug on trac.
I don't want to create a trac account just to report this single and
rather minor bug. If you would have wanted everyone to report bugs
there, you would allow it without account and then I wouldn't
Hi,
> Please do report this as a bug on trac.
I don't want to create a trac account just to report this single and
rather minor bug. If you would have wanted everyone to report bugs
there, you would allow it without account and then I wouldn't have used
this mailing list to report it in the first
On Wed, Jun 11, 2014 at 08:56:38AM -0400, Richard Heck wrote:
> On 06/11/2014 05:04 AM, Enrico Forestieri wrote:
> >
> >meaning that we rely upon something that indirectly sets the locale for us.
> >I think that the right fix is the attached one. After applying it,
> >QLocale::system() returns the
On 06/11/2014 05:04 AM, Enrico Forestieri wrote:
On Tue, Jun 10, 2014 at 07:57:46PM -0400, Richard Heck wrote:
On 06/10/2014 06:45 PM, Enrico Forestieri wrote:
On Wed, Jun 11, 2014 at 12:27:35AM +0200, Enrico Forestieri wrote:
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then t
On Tue, Jun 10, 2014 at 07:57:46PM -0400, Richard Heck wrote:
> On 06/10/2014 06:45 PM, Enrico Forestieri wrote:
> >On Wed, Jun 11, 2014 at 12:27:35AM +0200, Enrico Forestieri wrote:
> >>However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
> >>batch command succeeds, even if the ab
On 06/10/2014 06:45 PM, Enrico Forestieri wrote:
On Wed, Jun 11, 2014 at 12:27:35AM +0200, Enrico Forestieri wrote:
However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
batch command succeeds, even if the above output is unchanged.
Go figure...
Anyway, the attached patch fixes
On Wed, Jun 11, 2014 at 12:27:35AM +0200, Enrico Forestieri wrote:
>
> However, it is weird that compiling LyX 2.1 or 2.2 with Qt5, then the
> batch command succeeds, even if the above output is unchanged.
> Go figure...
Anyway, the attached patch fixes the issue for me, using either Qt4 or Qt5.
On Tue, Jun 10, 2014 at 08:59:18PM +0200, Claudius Marpa Heine wrote:
> Hi
>
> >
> > Have you tried getting rid of the umlaut in the logo's filename (and
> > in the related inset in lyx)?
> >
>
> Thanks, that did it.
>
> So is it a bug that it works in the UI and not in the terminal?
> Shouldn
On 06/10/2014 02:59 PM, Claudius Marpa Heine wrote:
Hi
Have you tried getting rid of the umlaut in the logo's filename (and
in the related inset in lyx)?
Thanks, that did it.
So is it a bug that it works in the UI and not in the terminal?
Shouldn't it support unicode paths in both cases?
I t
Hi
>
> Have you tried getting rid of the umlaut in the logo's filename (and
> in the related inset in lyx)?
>
Thanks, that did it.
So is it a bug that it works in the UI and not in the terminal?
Shouldn't it support unicode paths in both cases?
I thought it worked on a previous version.
Cheer
On Tue, Jun 10, 2014 at 12:07 PM, Claudius Marpa Heine <
claudius.marpa.he...@student.uni-augsburg.de> wrote:
> Hi LyX developers,
>
> I have a bug when I try to use LyX in a command line to create a pdf
> using pdflatex, but when I use LyX over the UI it works.
>
> H
Hi LyX developers,
I have a bug when I try to use LyX in a command line to create a pdf
using pdflatex, but when I use LyX over the UI it works.
Here is the command I use:
$ lyx -e pdf2 -f all test.lyx
Here is the simplest LyX file, where the bug occures:
https://dl.dropboxusercontent.com/u
06/02/2014 17:15, Jürgen Spitzmüller:
I've added your thoughts here, in case we get an application for GSOC 14 up
and running:
http://wiki.lyx.org/GSoC/GSoCProjectIdeasFor2014#toc4
Please revise.
Thanks for doing that Juergen.
JMarc
Jean-Marc Lasgouttes wrote:
> FWIW, I would like to propose for next GSoC (assuming we have a momentum
> towards submitting) a overhaul of out converter scheme where formats can
> be qualified through flags. For example, there would be only one pdf
> format (and one viewer), but
On Wed, Jan 29, 2014 at 5:22 AM, Jean-Marc Lasgouttes
wrote:
> 29/01/2014 09:59, Scott Kostyshak:
>
>> The conversion of image formats is already done because of LaTeX
>> (pdflatex) or at least it happens when I do Export > LaTeX
>> (pdflatex). I imagine the same is
29/01/2014 09:59, Scott Kostyshak:
The conversion of image formats is already done because of LaTeX
(pdflatex) or at least it happens when I do Export > LaTeX
(pdflatex). I imagine the same is true for external material, although
I did not test. So to me it seems like latex=pdflatex belongs
On Wed, Jan 29, 2014 at 3:41 AM, Jürgen Spitzmüller wrote:
> 2014-01-29 Scott Kostyshak
>
>> So in this case myfancyoutputformat would be used instead of LaTeX
>> (pdflatex)? If so, I now see why latex=pdflatex is needed.
>> What would be a use case for using myfanc
2014-01-29 Scott Kostyshak
> So in this case myfancyoutputformat would be used instead of LaTeX
> (pdflatex)? If so, I now see why latex=pdflatex is needed.
> What would be a use case for using myfancyoutputformat over LaTeX
> (pdflatex)? The only advantage I see would be control o
On Wed, Jan 29, 2014 at 3:01 AM, Jürgen Spitzmüller wrote:
> 2014-01-29 Scott Kostyshak
>
>> But aren't those already taken into account because of the "from" part
>> of a converter? For example, if it's from LaTeX (pdflatex) then the
>> output from
2014-01-29 Scott Kostyshak
> But aren't those already taken into account because of the "from" part
> of a converter? For example, if it's from LaTeX (pdflatex) then the
> output from LyX should already be set to pdflatex. But I guess there
> could be difference
On Wed, Jan 29, 2014 at 2:28 AM, Jürgen Spitzmüller wrote:
> 2014-01-29 Scott Kostyshak
>
>> I'm looking at the converter code and I would like to understand what
>> setting 'latex == pdflatex' (or any other flavor) does. In the
>> customization file, it s
2014-01-29 Scott Kostyshak
> I'm looking at the converter code and I would like to understand what
> setting 'latex == pdflatex' (or any other flavor) does. In the
> customization file, it states
> "This converter runs some form of LaTeX. This will make LyX's
I'm looking at the converter code and I would like to understand what
setting 'latex == pdflatex' (or any other flavor) does. In the
customization file, it states
"This converter runs some form of LaTeX. This will make LyX's LaTeX
error logs available."
but I think
On Sun, May 26, 2013 at 12:14 PM, Uwe Stöhr wrote:
> Am 26.05.2013 05:42, schrieb Uwe Stöhr:
>
>
>> This works for this special file but will of course fail when you use e.g.
>> an umlaut in the text. So
>> it turned out that adding "latin9" to the document class options is indeed
>> the proper so
Am 26.05.2013 05:42, schrieb Uwe Stöhr:
This works for this special file but will of course fail when you use e.g. an
umlaut in the text. So
it turned out that adding "latin9" to the document class options is indeed the
proper solution.
Maybe we should add this by default in the layout file -
Am 26.05.2013 03:13, schrieb Uwe Stöhr:
The support for aa was updated the last time 5 years ago. The latest aa class
loads now already the
package inputenc so that you got an option clash for inputenc. So the fix was
to update the layout
file.
This works for this special file but will of co
On Sat, May 25, 2013 at 9:26 PM, Uwe Stöhr wrote:
> Am 26.05.2013 02:24, schrieb Scott Kostyshak:
>
>
>> Good point. No, I do not think that would be good. I think that if
>> pdflatex fails, then a default format should definitely be set. If one
>> of the others fail
On Sat, May 25, 2013 at 9:30 PM, Uwe Stöhr wrote:
> Am 26.05.2013 03:27, schrieb Scott Kostyshak:
>
>
>>> Scott I appreciate your work and you uncover some problems. But why do
>>> you
>>> want to hide the bugs you just uncovered?
>
>
> I should have added a smiley here.
>
>
>> Because of ignoranc
Am 26.05.2013 03:27, schrieb Scott Kostyshak:
Scott I appreciate your work and you uncover some problems. But why do you
want to hide the bugs you just uncovered?
I should have added a smiley here.
Because of ignorance :). It is never my intention to hide a bug.
I know; that was meant with
On Sat, May 25, 2013 at 9:13 PM, Uwe Stöhr wrote:
> Am 25.05.2013 21:58, schrieb Scott Kostyshak:
>
>
>> On Sun, Apr 14, 2013 at 3:39 AM, Scott Kostyshak wrote:
>>>
>>> Exporting with luatex works fine. With pdflatex and ps2pdf I get an
>>> inp
Am 26.05.2013 02:24, schrieb Scott Kostyshak:
Good point. No, I do not think that would be good. I think that if
pdflatex fails, then a default format should definitely be set. If one
of the others fails, things are less clear. I think the best thing is
to choose a few. Currently we only test
Am 25.05.2013 21:58, schrieb Scott Kostyshak:
On Sun, Apr 14, 2013 at 3:39 AM, Scott Kostyshak wrote:
Exporting with luatex works fine. With pdflatex and ps2pdf I get an
inputenc option clash.
Is there a fix?
Adding 'latin9' as a class option fixes compilation for me. I will
c
On Sat, May 25, 2013 at 7:34 PM, Uwe Stöhr wrote:
> Am 25.05.2013 21:42, schrieb Scott Kostyshak:
>
> Yes, it is. In this case ps2pdf works so we have now several engines that
> work. LyX's default output format in the preferences is pdflatex and when a
> user changed this de
t;The default is pdflatex, so only experienced users who know te
differences will use ps2pdf. The
UserGuide explains the differences of the engines and why multi-step
converters can fail.
Are the contexts different?
Yes, it is. In this case ps2pdf works so we have now several engines that work.
On Sun, Apr 14, 2013 at 3:39 AM, Scott Kostyshak wrote:
> Exporting with luatex works fine. With pdflatex and ps2pdf I get an
> inputenc option clash.
>
> Is there a fix?
Adding 'latin9' as a class option fixes compilation for me. I will
commit this unless someone objects.
Scott
On Sat, May 25, 2013 at 12:26 PM, Uwe Stöhr wrote:
> Am 25.05.2013 08:44, schrieb Scott Kostyshak:
>
>> I can now compile all Hebrew documents with both ps2pdf and pdflatex.
>> When I compile with luatex, I get the following error:
>>
>> <<
>> To avoid th
Am 25.05.2013 08:44, schrieb Scott Kostyshak:
I can now compile all Hebrew documents with both ps2pdf and pdflatex.
When I compile with luatex, I get the following error:
<<
To avoid this error message,
run TeX--XeT or e-TeX engine instead of regular TeX.
! Right-to-Left Support Error: u
I can now compile all Hebrew documents with both ps2pdf and pdflatex.
When I compile with luatex, I get the following error:
<<
To avoid this error message,
run TeX--XeT or e-TeX engine instead of regular TeX.
! Right-to-Left Support Error: use TeX--XeT or e-TeX engine.
l.77 engine}
On Sat, May 18, 2013 at 10:01 PM, Uwe Stöhr wrote:
> Am 18.05.2013 14:34, schrieb Uwe Stöhr:
>
>
>> I can compile the file using pdflatex.
>
>
> After Kornel's mail I had a closer look ant it indeed failed on my laptop.
> It turned out that the additional graphics
Am 18.05.2013 14:34, schrieb Uwe Stöhr:
I can compile the file using pdflatex.
After Kornel's mail I had a closer look ant it indeed failed on my laptop. It turned out that the
additional graphics driver was the problem. dvips is already declared as driver in the layout file
but the ex
Am Samstag, 18. Mai 2013 um 14:34:40, schrieb Uwe Stöhr
> Am 18.05.2013 00:06, schrieb Scott Kostyshak:
> > On Sun, Apr 14, 2013 at 3:38 AM, Scott Kostyshak wrote:
> >> Exporting via ps2pdf works fine, but pdflatex and luatex fail. I think
> >> pdflatex fails because o
Am 18.05.2013 00:06, schrieb Scott Kostyshak:
On Sun, Apr 14, 2013 at 3:38 AM, Scott Kostyshak wrote:
Exporting via ps2pdf works fine, but pdflatex and luatex fail. I think
pdflatex fails because of converting the eps to pdf.
I thought I had fixed a similar error before with the following
On Sun, Apr 14, 2013 at 3:38 AM, Scott Kostyshak wrote:
> Exporting via ps2pdf works fine, but pdflatex and luatex fail. I think
> pdflatex fails because of converting the eps to pdf.
>
> I thought I had fixed a similar error before with the following:
>
> epstool --copy -
Exporting with luatex works fine. With pdflatex and ps2pdf I get an
inputenc option clash.
Note that examples/aa_sample.lyx exports with pdflatex and ps2pdf fine.
Is there a fix?
Scott
Exporting via ps2pdf works fine, but pdflatex and luatex fail. I think
pdflatex fails because of converting the eps to pdf.
I thought I had fixed a similar error before with the following:
epstool --copy --bbox platypus.eps --output platypus2.eps
But this did not help.
Any ideas?
Scott
On Sun, Feb 10, 2013 at 8:30 AM, Jürgen Spitzmüller wrote:
> Scott Kostyshak wrote:
>> Makes sense. Should we put a note in the LyX file?
>
> I don't know.
>
> This beamer cls is really old (and even a development version), I think this
> case really only concerns ubuntu users.
OK we can leave th
Scott Kostyshak wrote:
> Makes sense. Should we put a note in the LyX file?
I don't know.
This beamer cls is really old (and even a development version), I think this
case really only concerns ubuntu users.
Doesn't ubuntu update the latex packages from time to time? I mean, this
beamer class i
On Sun, Feb 10, 2013 at 6:21 AM, Jürgen Spitzmüller wrote:
> Scott Kostyshak wrote:
>> It exports well. However, beamer-article.lyx does not export. I get
>> "! LaTeX Error: Something's wrong--perhaps a missing \item."
>> and LyX attributes the error to the frame "Frame What are overlays?"
>
> Yes
Scott Kostyshak wrote:
> It exports well. However, beamer-article.lyx does not export. I get
> "! LaTeX Error: Something's wrong--perhaps a missing \item."
> and LyX attributes the error to the frame "Frame What are overlays?"
Yes, this is a known bug in beamer 2.10 which has been fixed long ago (
On Sat, Feb 9, 2013 at 9:57 AM, Jürgen Spitzmüller wrote:
> Scott Kostyshak wrote:
>> > Does it help if you put a {} in ERT just in front of the first "<" (but
>> > inside the alert inset)?
>>
>> Yes, after doing that, export with pdflatex works f
Scott Kostyshak wrote:
> > Does it help if you put a {} in ERT just in front of the first "<" (but
> > inside the alert inset)?
>
> Yes, after doing that, export with pdflatex works fine.
Can you re-try with most recent trunk?
Jürgen
cond one does not seem to play a role.
>
> Does it help if you put a {} in ERT just in front of the first "<" (but inside
> the alert inset)?
Yes, after doing that, export with pdflatex works fine.
Scott
Scott Kostyshak wrote:
> I meant the whole frame, but now I've narrowed it down to the
> "\alert{<\ldots{}>}". That is, the "<...>" following "embraced by".
> The second one does not seem to play a role.
Does it help if you put a {} in ERT just in front of the first "<" (but inside
the alert inse
On Sat, Feb 9, 2013 at 7:50 AM, Jürgen Spitzmüller wrote:
> Jürgen Spitzmüller wrote:
>> > Yes, if I remove "General overlay/action possibilities" it compiles fine.
>>
>> Can you pinpoint the problem even further on that frame?
>
> Let me ask differently: Do you mean you remove the text quoted abo
1 - 100 of 352 matches
Mail list logo
