On 11/24/22 06:56, Thibaut Cuvelier wrote:
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.ly
On Thu, Nov 24, 2022 at 12:56:54PM +0100, Thibaut Cuvelier wrote:
> 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:
> > >
> > >
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 notice that pdflatex is run, I think via lyxprev
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 pro
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-dev
>> On 2009-09-18, rgheck wrote:
> Things here are no different from the other output formats we support.
> Someone who adds a new feature already is supposed to take care of
> plaintext and DocBook output, as well as LaTeX, though, yes, I expect
> that I will likely end up helping out with this
Pavel Sanda wrote:
> i would let "View [Other formats]" to be "View (Other formats)"
> for better discernment from "View [format]".
OK.
> > > i still volunteer for adding the rc entry since
> > > clearly we are not able to agree what the good ui is.
> >
> >
> > No, please don't clutter the pref
Jürgen Spitzmüller wrote:
>I've done that. Please test.
i would let "View [Other formats]" to be "View (Other formats)"
for better discernment from "View [format]".
> > i still volunteer for adding the rc entry since
> > clearly we are not able to agree what the good ui is.
>
> No, please don't
Pavel Sanda wrote:
> > How about appending this to the entry then, as in "View [PDF
> > (pdflatex)]"?
>
> better than nothing.
I've done that. Please test.
> i still volunteer for adding the rc entry since
> clearly we are not able to agree what the good ui is.
No, please don't clutter the pr
Pavel Sanda wrote:
> i found another bug meanwhile - the other format in toolbar is not
> remembered through the sessions.
This is no bug. It is not supposed to do that (yet).
Jürgen
On 09/05/2009 02:08 PM, Alex Fernandez wrote:
On Sat, Sep 5, 2009 at 5:20 PM, rgheck wrote:
But that is precisely the point: We're not talking about four extra entries.
We're not going to do something special for HTML here, as much as you would
apparently like us to do so.
Actually I
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > eyes need to see the 'pdflatex' string somewhere in the menu to get quick
> > orientation and better on a constant place with other formats.
>
> How about appending this to the entry then, as in "View [PDF (pdflatex)]"?
better than nothing. i sti
Pavel Sanda wrote:
> eyes need to see the 'pdflatex' string somewhere in the menu to get quick
> orientation and better on a constant place with other formats.
How about appending this to the entry then, as in "View [PDF (pdflatex)]"?
Jürgen
Jürgen Spitzmüller wrote:
> It would be a duplicate of UI entries. I'm not opposed, but it's certainly
> not
> good UI design.
eyes need to see the 'pdflatex' string somewhere in the menu to get quick
orientation and better on a constant place with other formats.
i propose this patch. it could
Pavel Sanda wrote:
> nice, i see it now. there is small issue - the small down-arrow in the icon
> appears only after first use. this is intended?
No.
> my basic question was a bit different though - would you be against the
> inclusion the default output format in the view submenu?
It would b
Jürgen Spitzmüller wrote:
> Pavel Sanda wrote:
> > little bit of hijacking but anyway: the new formats machinery is kinda
> > confusing for me since i use and often switch between postscript and
> > pdf(latex) output. i can't use it directly from toolbar as it was till
> > now,
>
> Sure you can
Pavel Sanda wrote:
> little bit of hijacking but anyway: the new formats machinery is kinda
> confusing for me since i use and often switch between postscript and
> pdf(latex) output. i can't use it directly from toolbar as it was till
> now,
Sure you can. For instance, you can set the default
Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
> > I think that requesting such a feature is wrapping the bandage before
> > you get the cut: nobody has asked for it and it is likely it will
> > never be a problem anyway. Why not create different HTML converters
> > and see if it is actually a p
Le 05/09/2009 20:08, Alex Fernandez a écrit :
I just don't think that principles should always trump common sense.
Or that all formats are born equal.
Indeed. I _never_ use HTML for LyX documents ;)
JMarc
On Sat, Sep 5, 2009 at 5:20 PM, rgheck wrote:
> But that is precisely the point: We're not talking about four extra entries.
> We're not going to do something special for HTML here, as much as you would
> apparently like us to do so.
Actually I was not waiting for you to do it; I was volunteering
On 05/09/2009 17:20, Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I could have bet this will end like that ;-)
BTW, I get:
GuiApplication.cpp: In member function ‘virtual bool
lyx::frontend::GuiApplication::x11EventFilter(XEvent*)’:
GuiApplication.cpp:1641: error: ‘class lyx::
Abdelrazak Younes wrote:
> I could have bet this will end like that ;-)
BTW, I get:
GuiApplication.cpp: In member function ‘virtual bool
lyx::frontend::GuiApplication::x11EventFilter(XEvent*)’:
GuiApplication.cpp:1641: error: ‘class
On 09/05/2009 11:10 AM, Alex Fernandez wrote:
On Sat, Sep 5, 2009 at 4:51 PM, rgheck wrote:
Sure, why not. Maybe in a submenu. Otherwise why do you have them?
That would be the worry about clutter.
Thanks :) I understand the worry, I just don't share it in this instance.
S
On 05/09/2009 17:11, Jürgen Spitzmüller wrote:
Jürgen Spitzmüller wrote:
Your proposal meanwhile is "do the
dirty work I won't bother to do".
I did not say I don't bother to implement it. I said I do not have time at
the moment to finish what I've started. But I also proposed my
Jürgen Spitzmüller wrote:
> > Your proposal meanwhile is "do the
> > dirty work I won't bother to do".
>
> I did not say I don't bother to implement it. I said I do not have time at
> the moment to finish what I've started. But I also proposed my help.
Never mind. I finished the viewer part mys
On Sat, Sep 5, 2009 at 4:51 PM, rgheck wrote:
>> Sure, why not. Maybe in a submenu. Otherwise why do you have them?
>
> That would be the worry about clutter.
Thanks :) I understand the worry, I just don't share it in this
instance. Surely you can live with 4 additional entries in the Export
menu
On 09/05/2009 10:27 AM, Alex Fernandez wrote:
On Sat, Sep 5, 2009 at 3:55 PM, rgheck wrote:
LyX currently checks for htlatex, latex2html, and hevea, and it ought also
to check for plastex (I keep meaning to do that). I have all of these.
Should they all be on the menu, along with elyxer?
On Sat, Sep 5, 2009 at 3:55 PM, rgheck wrote:
> LyX currently checks for htlatex, latex2html, and hevea, and it ought also
> to check for plastex (I keep meaning to do that). I have all of these.
> Should they all be on the menu, along with elyxer?
Sure, why not. Maybe in a submenu. Otherwise why
On 09/05/2009 07:51 AM, Jürgen Spitzmüller wrote:
Alex Fernandez wrote:
1. Honestly, I can manage the Python part, but my C++ skills are
dubious at best. I am not confident to do this kind of development.
I was in the same situation when I started LyX development (minus the Python
ski
On 09/05/2009 08:17 AM, Alex Fernandez wrote:
Then you have not understood my proposal: I don't want to clutter the
menu at all. Tell me, how many HTML converters do you currently have
on your machine? If the answer is 0 or 1, you would get exactly the
same entries as you already have: 0 or 1. On
Alex Fernandez wrote:
> Then you have not understood my proposal: I don't want to clutter the
> menu at all. Tell me, how many HTML converters do you currently have
> on your machine?
I think 4 or 5.
> If the answer is 0 or 1, you would get exactly the
> same entries as you already have: 0 or 1.
On Sat, Sep 5, 2009 at 1:51 PM, Jürgen Spitzmüller wrote:
> You already said that you do not care about, e.g., CJKLyX converters. For
> others, these are crucial. Other users do not care about HTML converters,
> because they do not use it (me, for instance).
Sure, I do not care about them, but I d
Alex Fernandez wrote:
>1. Honestly, I can manage the Python part, but my C++ skills are
>dubious at best. I am not confident to do this kind of development.
I was in the same situation when I started LyX development (minus the Python
skills). In a sense, I still am.
> 2. I don't really think thi
On Sat, Sep 5, 2009 at 10:57 AM, Jürgen Spitzmüller wrote:
> OK, let's try to turn this discussion to a more productive direction. Do you
> want to volunteer to help us doing it properly?
No, sorry. I really can't because of a couple of reasons:
1. Honestly, I can manage the Python part, but my C
Jürgen Spitzmüller wrote:
> * in configure.py, check for \viewer_alternatives and
> \converter_alternatives next to the \viewer and \converter we already
> check for. That is: the first found viewer/converter in the list
> (currently the one that is used exclusively) is stored as \viewer or
>
Alex Fernandez wrote:
> But that is not the argument I am making. Instead, it is: this nice
> little hack solves a problem (HTML export with different tools) in the
> long term, and it does not add to the big issue (clutter in the export
> menu) significantly. The "better"
On 09/04/2009 05:25 PM, Sam Liddicott wrote:
Alex Fernandez wrote:
...
But that is not the argument I am making. Instead, it is: this nice
little hack solves a problem (HTML export with different tools) in the
long term, and it does not add to the big issue (clutter in the export
menu
Alex Fernandez wrote:
...
But that is not the argument I am making. Instead, it is: this nice
little hack solves a problem (HTML export with different tools) in the
long term, and it does not add to the big issue (clutter in the export
menu) significantly. The "better" solution is
say
"stop" to the twisted hacks and start doing things the right way,
since it is much better in the long run. The longer it takes for you
to say "stop" is the harder your life is going to be for a few years.
But that is not the argument I am making. Instead, it is: this nice
litt
On Friday 04 September 2009 Alex Fernandez wrote:
>
> So I would prefer to add different HTML converters first (since people
> are requesting that), and then worry about clutter. Sounds more
> logical to me.
Alex please notice that we have heard this kind of argument all over the
years, why don't
On Fri, Sep 4, 2009 at 3:34 PM, Jean-Marc Lasgouttes wrote:
> We can't add one menu entry corresponding to each possible use of each
> possible user/contributor. We have been doing this already too much, and
> from time to time it is nice to do some cleanup instead.?
Yes, it is nice, but IMHO the
Alex Fernandez wrote:
> I think that requesting such a feature is wrapping the bandage before
> you get the cut: nobody has asked for it and it is likely it will
> never be a problem anyway. Why not create different HTML converters
> and see if it is actually a problem. In that case, just undo the
Le 04/09/2009 15:32, rgheck a écrit :
A really nice option, I think, would be to allow
people to select more than one HTML converter to have available. And if
they did, then we could perhaps have a submenu that listed them.
And even to show in prefs the converters that are disabled because the
Le 04/09/2009 15:17, Alex Fernandez a écrit :
Please search the archieves. I've explained my POV several times in the past,
I'm too lazy to rephrase again.
Sorry, I can't find a thorough explanation, just terse one-liners like:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg150669.ht
On 09/04/2009 09:17 AM, Alex Fernandez wrote:
On Fri, Sep 4, 2009 at 3:09 PM, Jürgen Spitzmüller wrote:
Alex Fernandez wrote:
The information is not lost; it is a Reconfigure away. All you lost
are the possible customizations.
Please search the archieves. I've explained my P
On Fri, Sep 4, 2009 at 3:09 PM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> The information is not lost; it is a Reconfigure away. All you lost
>> are the possible customizations.
>
> Please search the archieves. I've explained my POV several times in the past,
> I'm too lazy to rephrase a
Alex Fernandez wrote:
> The information is not lost; it is a Reconfigure away. All you lost
> are the possible customizations.
Please search the archieves. I've explained my POV several times in the past,
I'm too lazy to rephrase again.
Jürgen
On Fri, Sep 4, 2009 at 1:02 PM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> Isn't that already in Preferences, under "External Formats"? You can
>> remove any converters you don't want.
>
> I'm not thinking of "removing", but of enabling/disabling (without losing
> given information).
The
Alex Fernandez wrote:
> Isn't that already in Preferences, under "External Formats"? You can
> remove any converters you don't want.
I'm not thinking of "removing", but of enabling/disabling (without losing
given information).
Jürgen
On Fri, Sep 4, 2009 at 10:54 AM, Jürgen Spitzmüller wrote:
> Alex Fernandez wrote:
>> What would be a proper way for you?
>
> Configure all available converters and let the user select in preferences
> which converters he wants to see in the menus.
Isn't that already in Preferences, under "Externa
Alex Fernandez wrote:
> What would be a proper way for you?
Configure all available converters and let the user select in preferences
which converters he wants to see in the menus.
Jürgen
On Fri, Sep 4, 2009 at 10:34 AM, Jürgen Spitzmüller wrote:
>> Would it be OK to
>> separate the formats into HTML (eLyXer), HTML (hevea) and so on? This
>> way users would be able to tell what they have installed and choose
>> between the different exporters if available.
>
> The same would need t
Alex Fernandez wrote:
> Would it be OK to
> separate the formats into HTML (eLyXer), HTML (hevea) and so on? This
> way users would be able to tell what they have installed and choose
> between the different exporters if available.
The same would need to be done for any other converter. But then,
Hi again,
I know this has been discussed before, but I still don't like the way
HTML is exported. The current situation is that LyX will look for
eLyXer, and if it is not found then it will use other options
(htlatex, hevea, or whatever) -- but all of them will be called HTML.
The user does not kn
Jean-Marc Lasgouttes wrote:
rgheck writes:
The issue here, I think, would be with eps and the like. LyX accepts a
lot of formats that one wouldn't assume browsers could display inline.
I think tex4ht by default converts everything to png.
Is there a list of valid formats somewhere? I
rgheck writes:
> The issue here, I think, would be with eps and the like. LyX accepts a
> lot of formats that one wouldn't assume browsers could display inline.
> I think tex4ht by default converts everything to png.
Is there a list of valid formats somewhere? I understand that svg, for
example,
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
For graphics I think we need two options:
1) link to the original file
2) resize to LateX settings and copy the graphic file to 'file.dir'
along 'file.html'
Why? We can use the original file but specify its size in the html,
can't
Pavel Sanda wrote:
There are enough MathML compliant browser out there, no need
to complicate our life with the bonus is that this will help the transition
to XML if we ever manage to do that. So, if I was you ;-), I'd implement
things in this order:
1) all images reusing the instant preview
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes writes:
For graphics I think we need two options:
1) link to the original file
2) resize to LateX settings and copy the graphic file to 'file.dir'
along 'file.html'
Why? We can use the original file but specify its size in the html,
can't
Abdelrazak Younes wrote:
>> There are also just a lot of questions about how to handle various things,
>> so I'd welcome any thoughts about that. E.g., what should we do with
>> InsetInclude? Include it?
i would include it by default
> Independently we should offer the
> option to split the fi
Abdelrazak Younes writes:
> For graphics I think we need two options:
> 1) link to the original file
> 2) resize to LateX settings and copy the graphic file to 'file.dir'
> along 'file.html'
Why? We can use the original file but specify its size in the html,
can't we?
> I think we should conside
rgheck wrote:
rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Jun 4 20:18:45 2009
New Revision: 29939
URL: http://www.lyx.org/trac/changeset/29939
This completes the major infrastructure for HTML output. Few of the
insets work yet, but it handles everything else reasonably well, even
tough
rgh...@lyx.org wrote:
Author: rgheck
Date: Thu Jun 4 20:18:45 2009
New Revision: 29939
URL: http://www.lyx.org/trac/changeset/29939
This completes the major infrastructure for HTML output. Few of the
insets work yet, but it handles everything else reasonably well, even
tough files like dev
Georg Baum wrote:
Richard Heck wrote:
Georg Baum wrote:
Richard Heck wrote:
Without any optional arguments, this script acts like dir_copy.py did:
It copies all files in LyX's temporary directory to a subdirectory of
the target directory. But now the script takes two optiona
Richard Heck wrote:
> Georg Baum wrote:
>> Richard Heck wrote:
>>
>>> Without any optional arguments, this script acts like dir_copy.py did:
>>> It copies all files in LyX's temporary directory to a subdirectory of
>>> the target directory. But now the script takes two optional arguments:
>>>
Enrico Forestieri wrote:
On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote:
This issue has proven to be difficult, so I think that your solution
is the less intrusive and workable one. I think that we should support
more actively the converters we look for, i.e., provide a -e switc
Georg Baum wrote:
Richard Heck wrote:
Without any optional arguments, this script acts like dir_copy.py did:
It copies all files in LyX's temporary directory to a subdirectory of
the target directory. But now the script takes two optional arguments:
-e: a list of extensions to copy, by de
On Fri, Jun 15, 2007 at 12:39:01AM -0400, Richard Heck wrote:
> This patch is now slightly updated. In place of the two scripts
> tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py.
> Without any optional arguments, this script acts like dir_copy.py did:
> It copies all files
Richard Heck wrote:
> This patch is now slightly updated. In place of the two scripts
> tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py.
I was about to suggest that.
> Without any optional arguments, this script acts like dir_copy.py did:
> It copies all files in LyX's tempo
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
Richard> The patch also includes some associated updates to the
Richard> documentation.
Jean-Marc> But not Extended.lyx.
Forget this. This patch does not get rid of originaldir.
JMarc
so I am inclined to give this my OK. Any objection?
Since there is no change to the code, the worst that can happen is
that HTML export does not work, which was the case already. So I think
it is safe.
JMarc
> "Richard" == Richard Heck <[EMAIL PROTECTED]> writes:
Richard> This new patch will allow easy handling of other converters,
Richard> such as hevea (and if anyone knows what kinds of files it
Richard> generates, let me know, and I'll add the definition to
Richard> configure.py).
The documen
On Friday 15 June 2007 05:39:01 Richard Heck wrote:
> Now seeking an OK to commit.
>
> Richard
Richard has gave this some thought and has tested this thoroughly so I am
inclined to give this my OK. Any objection?
--
José Abílio
This patch is now slightly updated. In place of the two scripts
tex4html_copy.py and dir_copy.py, there is now just one, ext_copy.py.
Without any optional arguments, this script acts like dir_copy.py did:
It copies all files in LyX's temporary directory to a subdirectory of
the target directo
Uwe Stöhr wrote:
Richard Heck schrieb:
The attached patch should finally make HTML export work properly.
As I wrote in bug 3090 the bug does no longer appear with MiKTeX 2.6
and tex4ht, but to assure that it works with all configurations, your
solution is the right one.
Some annotations
Enrico Forestieri wrote:
On Thu, Jun 14, 2007 at 06:49:17PM -0400, Richard Heck wrote:
Enrico Forestieri wrote:
On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote:
I've added two scripts: a dir_copy.py script, that simply copies the
entire temporary directory over to a
Richard Heck schrieb:
The attached patch should finally make HTML export work properly.
As I wrote in bug 3090 the bug does no longer appear with MiKTeX 2.6 and tex4ht, but to assure that
it works with all configurations, your solution is the right one.
Some annotations:
- htlatex is
On Thu, Jun 14, 2007 at 06:49:17PM -0400, Richard Heck wrote:
> Enrico Forestieri wrote:
> > On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote:
> >
> >
> >> I've added two scripts: a dir_copy.py script, that simply copies the
> >> entire temporary directory over to a subdirectory of
Enrico Forestieri wrote:
On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote:
I've added two scripts: a dir_copy.py script, that simply copies the
entire temporary directory over to a subdirectory of the intended output
directory, and a tex4html_copy.py script that copies only .png
On Thu, Jun 14, 2007 at 04:06:16PM -0400, Richard Heck wrote:
> I've added two scripts: a dir_copy.py script, that simply copies the
> entire temporary directory over to a subdirectory of the intended output
> directory, and a tex4html_copy.py script that copies only .png, .html,
> and .css fil
The attached patch should finally make HTML export work properly.
Various approaches to doing this were discussed on the list a while ago:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg118138.html
It eventually occurred to me, however, that the cleanest solution was
probably to
Richard Heck wrote:
> How do I get at these highly precise times? The boost file_write_time()
> function returns a time_t, which seems to be in seconds. (As you say,
> this may not work anyway.)
On BSD-like systems you could use
int utimes(const char *filename, const struct timeval tv[2]);
but
On Thu, May 24, 2007 at 11:55:35AM -0400, Richard Heck wrote:
> Georg Baum wrote:
> > Richard Heck wrote:
> >
> >
> >> That's the approach I'm now taking, more or less, as Enrico found yet
> >> further problems. He also suggested a simpler way, namely: note the time
> >> when we start the conver
Enrico Forestieri wrote:
> I don't think so as you would copy back all the graphics files (maybe
> converted to postscript from some bitmap format and thus huge) and all
> sort of things that gets copied to the tempdir.
>
> Why not implementing what I really proposed, i.e.,
> 1) make a list of all
, i.e.,
1) make a list of all file names which are present in the tempdir
just before calling htlatex
2) call htlatex
3) get a new list of files and copy back only those not present in
the first list
In this way the cruft copied back would be greatly reduced as .log,
.dvi, and .aux file would not b
Georg Baum wrote:
> Richard Heck wrote:
>
>
>> That's the approach I'm now taking, more or less, as Enrico found yet
>> further problems. He also suggested a simpler way, namely: note the time
>> when we start the conversion; then look at the modification times of the
>> files after the conversi
Richard Heck wrote:
> That's the approach I'm now taking, more or less, as Enrico found yet
> further problems. He also suggested a simpler way, namely: note the time
> when we start the conversion; then look at the modification times of the
> files after the conversion to see which ones got gener
Georg Baum wrote:
>> I didn't. I meant it should copy it to the NEW temporary directory, e.g.:
>> /tmp/lyx_098weras/lyx_tmpbuf0/file.html.conversion/
>> which is where the converted files will be dumped.
>>
> Why not do that in LyX (with the copier to fix paths of included files) and
> call th
Richard Heck wrote:
> Georg Baum wrote:
>> Richard Heck wrote:
>>
>>
>>> This is the result of a problem that Uwe noticed the other day with the
>>> MikTeX implementation of the htlatex scripts: The scripts will not run
>>> properly unless they are run in the same directory as the original file
Never mind...see the other message.
Enrico Forestieri wrote:
> On Wed, May 23, 2007 at 06:04:59PM -0400, Richard Heck wrote:
>
>> Enrico (and anyone else who is interested),
>>
>> Can you try one and let me know if it works properly on Windows? I
>> believe it should, even with the broken htla
On Wed, May 23, 2007 at 06:04:59PM -0400, Richard Heck wrote:
>
> Enrico (and anyone else who is interested),
>
> Can you try one and let me know if it works properly on Windows? I
> believe it should, even with the broken htlatex. The idea is to copy
> whatever files we need to the temporary co
Enrico (and anyone else who is interested),
Can you try one and let me know if it works properly on Windows? I
believe it should, even with the broken htlatex. The idea is to copy
whatever files we need to the temporary conversion directory. Then we
can do everything without paths.
Richard
--
Georg Baum wrote:
> Richard Heck wrote:
>
>
>> This is the result of a problem that Uwe noticed the other day with the
>> MikTeX implementation of the htlatex scripts: The scripts will not run
>> properly unless they are run in the same directory as the original file.
>>
> Several other con
Richard Heck wrote:
>
> This is the result of a problem that Uwe noticed the other day with the
> MikTeX implementation of the htlatex scripts: The scripts will not run
> properly unless they are run in the same directory as the original file.
Several other converters (e.g. lilypond) have the sa
This is the result of a problem that Uwe noticed the other day with the
MikTeX implementation of the htlatex scripts: The scripts will not run
properly unless they are run in the same directory as the original file.
So you can't run e.g. htlatex C:/path/to/file.tex. You can only run
htlatex file.t
i get
An error occurred whilst running htlatex "C:/tmp/lyx_tmpdir2696a00632/lyx_tmpbuf
1/t
more here:
pplatex: Process input file teachers.dvi
pplatex: Copy data to teachers.dvi
pplatex: Process input file teachers.dvi
pplatex: Copy data to teachers.dvi
C:\tmp\lyx_tmpdir2696a00632\lyx_tmpbuf1
i get:
1>..\..\trunk\src\Exporter.cpp(275) : error C4101: 'e' : unreferenced local
variable
Herbert Voss wrote:
>> && contains(buffer->filePath(), ' ')) {
>> Alert::error(_("File name error"),
>> - _("The directory path to the document cannot contain
>> spaces."));
>> + _("The directory path to the document cannot c
Richard Heck wrote:
> This patch has been to the list previously and been more or less
> approved. I'm sending it again, however, as I've made some additional
> changes and it should be tested by at least one other person, I think,
> before I commit. If you do test, please test: (i) View>HTML; (ii)
This patch has been to the list previously and been more or less
approved. I'm sending it again, however, as I've made some additional
changes and it should be tested by at least one other person, I think,
before I commit. If you do test, please test: (i) View>HTML; (ii)
File>Export>HTML; (iii) Fi
1 - 100 of 121 matches
Mail list logo
