On 1/27/24 12:37, Pavel Sanda wrote:
On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote:
With this second version the pdf preview is also perfect !
Good, committed as 7eb5003a81ab. Will be part of RC2,
for your convenience you can leave the new configure.py
within your local R
On Sat, Jan 27, 2024 at 05:30:19PM +0100, didiergab...@free.fr wrote:
> With this second version the pdf preview is also perfect !
Good, committed as 7eb5003a81ab. Will be part of RC2,
for your convenience you can leave the new configure.py
within your local RC1 installation...
Pavel
--
lyx-dev
On Sat, Jan 27, 2024 at 06:05:02PM +0100, didiergab...@free.fr wrote:
> After setting up this version of the ???configure.py??? script I no longer
> find any trace of the file converter:
> PDF (graphic) ???> PNG with the command:
> ???pdftoppm -r 72 -png -singlefile $$i > $$o???
>
> Can you co
After setting up this version of the “configure.py” script I no longer find any
trace of the file converter:
PDF (graphic) —> PNG with the command:
“pdftoppm -r 72 -png -singlefile $$i > $$o”
Can you confirm that this is normal? (I tell myself that I may have clicked on
the “remove” button by
With this second version the pdf preview is also perfect !
- Mail original -
| On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote:
| > On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr
| > wrote:
| > > It's perfect ! See for yourself???
| >
| > Good. I will need to
On Sat, Jan 27, 2024 at 02:29:15PM +0100, Pavel Sanda wrote:
> On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr wrote:
> > It's perfect ! See for yourself???
>
> Good. I will need to prepare more generic patch for you to test.
Didier, please test the generic version of configure.py
On Sat, Jan 27, 2024 at 01:43:02PM +0100, didiergab...@free.fr wrote:
> It's perfect ! See for yourself???
Good. I will need to prepare more generic patch for you to test.
Stay tuned,
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
ps :
But be careful, I'll come back with another question in a few minutes... On the
list of simple users... For a story about the background color of an svg
graphic... ;o)
- Mail original -
| It's perfect ! See for yourself…
| Thank’s
| Thank you so much !
| ps:
| - Mail orig
On Sat, Jan 27, 2024 at 01:16:39PM +0100, didiergab...@free.fr wrote:
> I see where the ???cache??? folder is located in my user directory here :
>
> C:\Users\Didier\AppData\Roaming\LyX2.4\cache
>
> And I just spotted the configure.py file here:
>
> C:\Users\Didier\AppData\Local\Programs\LyX
I see where the “cache” folder is located in my user directory here :
C:\Users\Didier\AppData\Roaming\LyX2.4\cache
And I just spotted the configure.py file here:
C:\Users\Didier\AppData\Local\Programs\LyX 2.4\Resources
So ok ?
- Mail original -
| On Sat, Jan 27, 2024 at 12:48:40P
On Sat, Jan 27, 2024 at 12:48:40PM +0100, didiergab...@free.fr wrote:
> I'm a little lost, because I managed the discussion threads very poorly and I
> didn't always place my comments in the right places...
Do not worry, we will manage.
> You would like the screenshot showing the preview of the
On Tue, Jan 23, 2024 at 09:22:23PM +0100, Thibaut Cuvelier wrote:
> On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote:
>
> > On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> > > pdftoppm -r 72 -png -singlefile $$i > $$o
> >
> > This is new route in 2.4 which can be used
On Tue, 23 Jan 2024 at 18:35, Pavel Sanda wrote:
> On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> > pdftoppm -r 72 -png -singlefile $$i > $$o
>
> This is new route in 2.4 which can be used to avoid IM problems in linux.
> We perhaps triggerred unnecessary problems o
On 1/23/24 12:33, Pavel Sanda wrote:
On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
pdftoppm -r 72 -png -singlefile $$i > $$o
This is new route in 2.4 which can be used to avoid IM problems in linux.
We perhaps triggerred unnecessary problems on Windows.
This could
On Tue, Jan 23, 2024 at 11:58:54AM -0500, Richard Kimberly Heck wrote:
> pdftoppm -r 72 -png -singlefile $$i > $$o
This is new route in 2.4 which can be used to avoid IM problems in linux.
We perhaps triggerred unnecessary problems on Windows.
This could be sovled by making pdftoppm addition
Here it is.
Here is the command I can see under Tools> Preferences> File Handling>
Converters, at the PDF to PNG converter: « pdftoppm -r 72 -png -singlefile $$i
> $$o » as you said... I’ll try to increase the dpi
ps : On these computer svg from inkscape preview is ok so good point.
- M
On 1/23/24 04:06, didiergab...@free.fr wrote:
I am currently in front of my Windows 10 PC at my workplace with which
I am experiencing exactly the same symptoms.
I followed your instructions, and you will find the requested file
attached.
I will do the same thing again this evening at home, with
On Thu, Jun 14, 2018 at 06:37:17PM +, Kornel Benko wrote:
> Am Donnerstag, 14. Juni 2018 13:51:33 CEST schrieb Scott Kostyshak
> :
> > On Thu, Jun 14, 2018 at 09:26:39AM +, Kornel Benko wrote:
> > > Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak
> > > :
> > > > On Thu,
Am Donnerstag, 14. Juni 2018 13:51:33 CEST schrieb Scott Kostyshak
:
> On Thu, Jun 14, 2018 at 09:26:39AM +, Kornel Benko wrote:
> > Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak
> > :
> > > On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> > > > The graphic
Am Donnerstag, 14. Juni 2018 03:01:51 CEST schrieb Scott Kostyshak
:
> On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> > The graphics display looks wrong if cache is enabled.
> > Attached versions of oxygen fonts.svgz.
> > (Master and 2.3.x show the same behavior)
> > (Some croppi
On Thu, May 10, 2018 at 11:32:37AM +, Kornel Benko wrote:
> The graphics display looks wrong if cache is enabled.
> Attached versions of oxygen fonts.svgz.
> (Master and 2.3.x show the same behavior)
> (Some cropping error on the upper side?)
What are the steps to reproduce?
Scott
signatur
Richard Kimberly Heck wrote:
> On 06/07/2018 02:56 AM, Pavel Sanda wrote:
> > Scott Kostyshak wrote:
> >> This is the same issue as discussed here:
> >>
> >> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
> > Indeed, when the patch in master is applied to branch the problem
On 06/07/2018 02:56 AM, Pavel Sanda wrote:
> Scott Kostyshak wrote:
>> This is the same issue as discussed here:
>>
>> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
> Indeed, when the patch in master is applied to branch the problem is gone.
I guess we'd better apply that
Scott Kostyshak wrote:
> This is the same issue as discussed here:
>
> https://www.mail-archive.com/search?l=mid&q=1603612.ofyPDf553K%40amd64
Indeed, when the patch in master is applied to branch the problem is gone.
Pavel
On Wed, Jun 06, 2018 at 09:49:09PM +, Pavel Sanda wrote:
> Taking back. To correctly reproduce the problem, one needs to empty the
> image cache. Bisect then leads to:
>
> commit a1579c583acb22a7f5dae80a9bfe7707774f49a4
This is the same issue as discussed here:
https://www.mail-archive.com
On 02/03/2011 11:27 AM, Richard Heck wrote:
In attempting to look at #7163, I have found that graphics are no
longer being converted in the background, after the Buffer loads. The
reason seems to be r29473, which is triggering a metrics calculation
for the whole Buffer that is then forcing ea
Yes, the graphics reload command solves the problem!
Dave Raymond
Vincent van Ravesteijn writes:
> David Raymond schreef:
> > If one imports a graphics file into a lyx document, close the
> > document, and then delete the graphics file, the next time that the
> > document is opened, lyx repo
I actually deleted the image and restarted lyx. I then recreated the
image and lyx couldn't find it even if I deleted the graphic from the
document and added it to the document again. Let me try the graphics
reload feature -- I didn't notice that.
Dave Raymond
Vincent van Ravesteijn writes:
>
David Raymond schreef:
If one imports a graphics file into a lyx document, close the
document, and then delete the graphics file, the next time that the
document is opened, lyx reports that the graphics file cannot be
found. Fair enough. However, if the graphics file is recreated while
lyx stil
2009/3/3 Bob Wonderly :
> I have a LyX math book in the works. It is in landscape format so I can show
> wide page sized graphics -- PDF files (generated by gnuplot and converted to
> PDF by AquaTerm).
>
> The output book file (using pdflatex) shows only part of the graphic.
> Nothing I have tried
> which probably does what you want. It may make more sense however to
> have a version that requires a reference directory as argument.
just a question .. does this somehow interfere with the new embeding stuff
in 1.6?
pavel
Vasek Smidl <[EMAIL PROTECTED]> writes:
> Yeah, I think it is the latter.
> In changeset/3881 the detection is:
> (IsFileReadable(MakeAbsPath(params().filename, buf->filePath()))
>
> while now it is:
>isFileReadable(params().filename);
>
> So it is checked by a different function, (lowerca
Pavel Sanda <[EMAIL PROTECTED]> writes:
>
> > I came across the situation when some of my older lyx files could no longer
> > compile under new versions of LyX.
Well, the file is about 5 years old, and I haven't tried to compile it since, so
the problem may actually be there quite a long time.
> I came across the situation when some of my older lyx files could no longer
> compile under new versions of LyX.
looking on the commit history this line has been introduced by Herbert
http://www.lyx.org/trac/changeset/3881
and the only interesting change was made by
http://www.lyx.org/trac/ch
Andre Poenitz wrote:
Probably. After the merging there's quite some cruft of the
thin-wrapper-around-misbehaving-thin-wrappers style left.
Bugfixing might be as simple as removing stuff...
i put it in:
http://www.lyx.org/trac/changeset/20172
On Sun, Sep 09, 2007 at 01:50:32PM +0200, Edwin Leuven wrote:
> Edwin Leuven wrote:
> >the attached makes it usable again...
>
> and i guess these can all go
Probably. After the merging there's quite some cruft of the
thin-wrapper-around-misbehaving-thin-wrappers style left.
Bugfixing might be as
On Sun, Sep 09, 2007 at 01:06:35PM +0200, Edwin Leuven wrote:
> the attached makes it usable again...
Thanks.
Andre'
Edwin Leuven wrote:
the attached makes it usable again...
and i guess these can all go
Index: src/frontends/qt4/GuiExternal.cpp
===
--- src/frontends/qt4/GuiExternal.cpp (revision 20164)
+++ src/frontends/qt4/GuiExternal.cpp (worki
Michael Gerz schrieb:
Something for the python gurus:
File "C:/Dokumente und Einstellungen/user/Lokale
Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py", line 11
SyntaxError: Non-ASCII character '\xc3' in file C:/Dokumente und
Einstellungen/user/Lokale
Einstellungen/Temp/lyx_tmpdir4040
On Thursday 28 December 2006 18:20, Michael Gerz wrote:
> Something for the python gurus:
>
> File "C:/Dokumente und Einstellungen/user/Lokale
> Einstellungen/Temp/lyx_tmpdir4040a03468/lyxconvert0.py", line 11
> SyntaxError: Non-ASCII character '\xc3' in file C:/Dokumente und
> Einstellungen/user
On Aug 6, 2006, at 10:00 PM, TJ wrote:
Ive been searching around the web for an answer to this problem and
can find nothing. I am running a Mac with the latest version of OS
X and I have followed the installation page that I found on one of
the Lyx.org linked sites. My question is when I pu
Am Samstag, 9. Juli 2005 00:33 schrieb João Luis Meloni Assirati:
> There is a problem with the patch:
Thanks for spotting this. It is fixed now. Parts from the next patch
slipped in ;-)
Georg
Georg,
Em Sex 08 Jul 2005 12:11, Georg Baum escreveu:
> Angus Leeming wrote:
> > Ok, the problem is that ChangeExtension calls os::internal_path
> > internally, so the \ characters here are converted to / ones:
> > path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
>
> Attached
Georg Baum wrote:
>> Ok, the problem is that ChangeExtension calls os::internal_path
>> internally, so the \ characters here are converted to / ones:
>> path = ChangeExtension("\\string\"" + base + "\\string\"",
>> ext);
>
> Attached is the equivalent patch for 1.4. Note that I also cha
Angus Leeming wrote:
> Ok, the problem is that ChangeExtension calls os::internal_path
> internally, so the \ characters here are converted to / ones:
> path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
Attached is the equivalent patch for 1.4. Note that I also changed the
ex
Angus Leeming wrote:
Ok, the problem is that ChangeExtension calls os::internal_path
internally, so the \ characters here are converted to / ones:
path = ChangeExtension("\\string\"" + base + "\\string\"", ext);
I'm compiling the version of latex_path below and will report back in
the mor
Angus Leeming wrote:
Can you see why it doesn't work:
\begin{flushleft}\includegraphics[%
width=0.9\columnwidth,
height=0.5\columnwidth]{/string"C:/Documents and Settings/Angus/Local
Settings/Temp/lyx_tmpdir5900a04256/lyx_tmpbuf0/J__MinSYS_home_Angus_ekkehart2_im_ages_picture/string".eps}
Angus Leeming wrote:
Georg Baum wrote:
Angus Leeming wrote:
Than please commit it and I'll fire up the Windows box.
Done. I really hope that it works now :-) If it does, I'll prepare a
similar patch for 1.4.
I'll try and find some time this evening to compile it and the latest
Qt/Win Free
Georg Baum wrote:
> Angus Leeming wrote:
>> Than please commit it and I'll fire up the Windows box.
> Done. I really hope that it works now :-) If it does, I'll prepare a
> similar patch for 1.4.
I'll try and find some time this evening to compile it and the latest
Qt/Win Free which should fix ke
Angus Leeming wrote:
> Than please commit it and I'll fire up the Windows box.
Done. I really hope that it works now :-) If it does, I'll prepare a similar
patch for 1.4.
Georg
Georg Baum wrote:
>> Don't we therefore need:
>> \includegraphics{\string"my dir/my picture\string".png}
> Yes. And the patch should exactly do that! If it does not, please shout!
Than please commit it and I'll fire up the Windows box.
--
Angus
Angus Leeming wrote:
> Hm. I read this as outputting
> \includegraphics{\string"my dir/my picture\string"}
No. The magic happens in latex_path: strip extension, add quotes, add
extension.
> I thought that missing out the extension would break latex?
Yes.
> Don't we
> therefore need:
>
Georg Baum wrote:
> Conclusion: We can't make spaces work with pdfetex from tetex, but we can
> support them on miktex. Therefore I propose the following patch for 1.3.6
> (I'll send a similar one for 1.4 if this is OK).
Hm. I read this as outputting
\includegraphics{\string"my dir/my pic
Am Donnerstag, 30. Juni 2005 11:23 schrieb Angus Leeming:
> the attached .tex file can be compiled with pdflatex here (MikTeX). The
> latex compiler is happy with the equivalent .eps ending to
> ...picture\string".png}
>
> Of course, this is a doctored file because current cvs outputs
> ...pict
Georg Baum wrote:
I attach my version of graphicx.sty.
Could you try it bei Dir?
I will do so tomorrow evening when I get to the machine with tetex 3.0
again.
Thank you.
From our previuos investigations I know that (according to the version
numbers) our versions of pdfetex, graphicx.sty an
Angus Leeming wrote:
> You tell me that your teTeX 3.0 version of pdflatex likes the second
> flavour but not the first? Is that a function of the compiler or of the
> graphicx.sty?
I don't know.
> $ pdflatex --version
> MiKTeX-pdfetex 2.4.1862 (1.21a) (MiKTeX 2.4)
> Copyright (C) 1982 D. E. Kn
Jean-Marc Lasgouttes wrote:
Angus> Jean-Marc Lasgouttes wrote: You tell me that your teTeX 3.0
Angus> version of pdflatex likes the second flavour but not the first?
Angus> Is that a function of the compiler or of the graphicx.sty?
I guess the difference is more likely to be in pdftex.def, whic
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc Lasgouttes wrote: You tell me that your teTeX 3.0
Angus> version of pdflatex likes the second flavour but not the first?
Angus> Is that a function of the compiler or of the graphicx.sty?
>> I guess the difference is more l
Jean-Marc Lasgouttes wrote:
Angus> You tell me that your teTeX 3.0 version of pdflatex likes the
Angus> second flavour but not the first? Is that a function of the
Angus> compiler or of the graphicx.sty?
I guess the difference is more likely to be in pdftex.def, which is
supposed to be the graph
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> You tell me that your teTeX 3.0 version of pdflatex likes the
Angus> second flavour but not the first? Is that a function of the
Angus> compiler or of the graphicx.sty?
I guess the difference is more likely to be in pdftex.def, whi
On Tue, May 31, 2005 at 11:12:26AM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
> Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex,
> Angus> I don't
Michael Schmitt wrote:
Angus Leeming wrote:
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
Please report back if LaTeX is happy.
LaTeX is happy and I am happy, too :-)
Then I'll commit the patch... Done.
What astonishes me is the fact that LyX 1.4 works without a
Angus Leeming wrote:
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
Please report back if LaTeX is happy.
LaTeX is happy and I am happy, too :-)
What astonishes me is the fact that LyX 1.4 works without a patch. Maybe
it converts paths before the character check..
Jean-Marc Lasgouttes wrote:
> Angus> One thing that I have noticed (not a bug, but an inconsistency)
> Angus> is that in the Preferences dialog, the Paths pane displays all
> Angus> paths in UNIX style. This looks a little odd because at the
> Angus> bottom of the list is the "prepend_path" variabl
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> One thing that I have noticed (not a bug, but an inconsistency)
Angus> is that in the Preferences dialog, the Paths pane displays all
Angus> paths in UNIX style. This looks a little odd because at the
Angus> bottom of the list is th
Jean-Marc Lasgouttes wrote:
> Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
> Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex,
> Angus> I don't see why a ':' in a file name won't work, but you're the
> Angus> one using this stuff...
>
> I guess ':'
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Reading http://wiki.lyx.org/LaTeX/FilesWithSpecialChars and
Angus> http://wiki.lyx.org/uploads/LaTeX/FilesWithSpecialChars/filenames.tex,
Angus> I don't see why a ':' in a file name won't work, but you're the
Angus> one using this s
Michael Schmitt wrote:
> Angus,
>
> I tried to insert a graphics which is located in directory
> C:\blabla\blabla. However, LyX 1.3.6cvs complains about the path
> containing invalid character ":". Didn't this work before?
In src/frontends/controllers/helper_funcs.C, try removing the ':' from
Alfredo Braunstein wrote:
>
> Garst R. Reese wrote:
>
> > It severly impacts scrolling thru a doc.
> > Every time a grapic is loaded the cursor jumps to the the top of the
> > document.
>
> Is it the top of the document or the cursor position?
Top of document.
> Does this solves it?
>
Yes.
T
Garst R. Reese wrote:
> It severly impacts scrolling thru a doc.
> Every time a grapic is loaded the cursor jumps to the the top of the
> document.
Regards, Alfredo
Is it the top of the document or the cursor position?
Does this solves it?
Index: BufferView_pimpl.C
=
Angus Leeming wrote:
> Garst, could you expand further? I've just looked at the ChangeLogs
My mistake. It was July 21, and that seems too early.
G.
Garst R. Reese wrote:
> If the ChangeLogs are any indication, this probably started with
> Angus on Aug 21.
> It severly impacts scrolling thru a doc.
> Every time a grapic is loaded the cursor jumps to the the top of the
> document.
Garst, could you expand further? I've just looked at the Change
On Fri, May 30, 2003 at 02:24:22AM +0100, John Levon wrote:
> > I believe we should *always* store an absolute path at
> > runtime. At save time, we can convert it to a relative path.
Fixed patch. It seems to work for me. It fixes the Save As bug.
Please please test.
john
p.s. sorry, no, I'm n
On Fri, May 30, 2003 at 01:49:28AM +0100, John Levon wrote:
> I believe we should *always* store an absolute path at
> runtime. At save time, we can convert it to a relative path.
Here's an attempt at a patch. Not tested
john
Index: insetgraphics.C
=
Angus Leeming wrote:
> Ok, so:
> std::queue tmp;
> swap(bucket1_, tmp;
> Still no need to pollute the class interface...
You are right (as always). Done, thanks.
I'll try to send something to the list this evening. Right now I need to get
some real life work done...
In the meant
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>> There is still no need to have bucket2_ as a class member...
>>
>> void LoaderQueue::emptyBucket()
>> {
>> cout << "emptying bucket" << endl;
>> std::queue tmp = bucket1_;
>> while (!tmp.empty()) {
>> a
Angus Leeming wrote:
> There is still no need to have bucket2_ as a class member...
>
> void LoaderQueue::emptyBucket()
> {
> cout << "emptying bucket" << endl;
> std::queue tmp = bucket1_;
> while (!tmp.empty()) {
> addToQueue(tmp.front());
>
Andre Poenitz wrote:
> On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote:
>> > It doesn't depend on BufferView. Why not make it a singleton class?
>>
>> Sure... what's a singleton class?
>
> Just put it into a class and create just one object of it.
> [The rest is rather ideolog
Alfredo Braunstein wrote:
>> exit to the method. In fact why not:
>> +void LoaderQueue::emptyBucket()
>> +{
>> + cout << "emptying bucket" << endl;
>> + while (! bucket1_.empty()) {
>> + addToQueue(bucket1_.front());
>> + bucket1_.pop();
>> + }
>> +}
>
On Thu, Feb 20, 2003 at 02:15:06PM +0100, Alfredo Braunstein wrote:
> > It doesn't depend on BufferView. Why not make it a singleton class?
>
> Sure... what's a singleton class?
Just put it into a class and create just one object of it.
[The rest is rather ideology]
Andre'
--
Those who des
Angus Leeming wrote:
> It doesn't depend on BufferView. Why not make it a singleton class?
Sure... what's a singleton class?
> bucket1_ is filled with Cache::ItemPtrs to be dealt with by
> LoaderQueue::touch.
>
> The timer calls LoaderQueue::loadNext every 100 ms.
>
> LoaderQueue::loadNext cal
Alfredo Braunstein wrote:
> A second option for LoaderQueue.
> I've left the previous interface untouched, but changed a little the
> implementation. Now touch() doesn't add directly the image pointer to the
> queue, but it adds it to an input bucket (implemented as a plain queue)
> without any ch
Alfredo Braunstein wrote:
> PS: using previews with current cvs, I get a strange behaviour. In a new
> document, make a math inset (like... C-m 1 esc). Then Latex and dvipsk are
> called twice. Does anyone else see it? Is it intended? Why?
Yes I see it. No it's not. Don't know.
--
Angus
Angus Leeming wrote:
> Actually, after I wrote this, I think that your code is perfect as it
> is. No need for the isInsetVisible stuff or the 2 second pause at all.
>
> Moreover, if you modified GraphicsConverter as well so that it
> created a queue of scripts to execute sequentially, as describ
Alfredo Braunstein wrote:
>> We have a nice ForkedCall class that emits a signal when the forked
>> process ends. We could have a function processQueue() that pops a
>> single item off the queue and forks a process with it. When it
>> finishes, the ForkedCall emits a signal which LyX uses to start
Hi Angus,
Angus Leeming wrote:
> No, I thought you said that you posted it for examination only?
It is in a working state. I meant the obvious: is not for applying to cvs
(said mostly to cover my back with dignity if you rejected it in disgust :)
>> If you scroll fast, then all insets not load
Andre Poenitz wrote:
> On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
>> So, call André the wizard and call me his apprentice, Mickey Mouse.
>
> And just to give some insight into what makes a wizard in Angus'
> eyes:
>
> One has to be too dumb to understand anything spanning mor
On Wed, Feb 19, 2003 at 01:24:15PM +, Angus Leeming wrote:
> So, call André the wizard and call me his apprentice, Mickey Mouse.
And just to give some insight into what makes a wizard in Angus' eyes:
One has to be too dumb to understand anything spanning more than a
screenful of code or more
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>>> I see. But draw() is called for all insets at startup time, right?
>>
>> Yes. That's why we have to have this "see if the inset is visible"
>> check (uses GraphicsSupport's isInsetVisible.)
>>
>> The two second pause between the call to Ins
Angus Leeming wrote:
>> I see. But draw() is called for all insets at startup time, right?
>
> Yes. That's why we have to have this "see if the inset is visible"
> check (uses GraphicsSupport's isInsetVisible.)
>
> The two second pause between the call to Inset::draw and
> Loader::Impl::checkedL
Alfredo Braunstein wrote:
>> In all cases the loading of the image is triggered by the Inset's
>> draw() method. Eg InsetGraphics::draw has
>>if (cache_->loader.status() == grfx::WaitingToLoad)
>> cache_->loader.startLoading(*this, *bv);
>
> I see. But draw() is called for
Angus Leeming wrote:
Hi Angus, thanks for the answers.
> I can answer that. Three classes are interested in graphics.
> insets/insetgraphics.C together with mathed/formula.C and
> insets/insetinclude.C for the previews. These latter two have
> instances of a class PreviewImpl that derives from
>
Alfredo Braunstein wrote:
> I'm fiddling a little with the graphics loader, and I started to
> implement a pseudo threaded version of it (patch attached).
>
> It works as follows: there is this LoaderQueue class (I think every
> BufferView should have one, right now is simply a global class),
> w
Andre Poenitz wrote:
> On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
>> Right now it's implemented as a queue + a set, so it's O(ln n) for the
>> 'first time insert' case, and O(n) for the 'already have it' case.
>> I plan to make it O(ln n) always.
>
> Good idea, but we do
On Wed, Feb 19, 2003 at 09:43:09AM +0100, Alfredo Braunstein wrote:
> Right now it's implemented as a queue + a set, so it's O(ln n) for the
> 'first time insert' case, and O(n) for the 'already have it' case.
> I plan to make it O(ln n) always.
Good idea, but we do pretty expensive things in othe
On Mon, Oct 28, 2002 at 06:24:52PM +0900, Rob Lahaye wrote:
> Dekel Tsur wrote:
> >No. There are only \textheight and \pageheight.
> >
>
> We then would get:
>
> labeltext widthheight
>
> text%\textwidth \textheight
> page
For me it is o. k.
--
Regards, Hartmut
Hungerhilfe: http://www.thehungersite.com
ATTAC - für eine solidarische weltwirtschaft
gegen neoliberale globalisierung: http://www.attac-netzwerk.de
Mitmachen bei der GATS-Kampagne: http://www.attac-netzwerk.de/gats/
www
For me it is o. k.
--
Regards, Hartmut
Hungerhilfe: http://www.thehungersite.com
ATTAC - für eine solidarische weltwirtschaft
gegen neoliberale globalisierung: http://www.attac-netzwerk.de
Mitmachen bei der GATS-Kampagne: http://www.attac-netzwerk.de/gats/
www
> "Michael" == Michael Schmitt <[EMAIL PROTECTED]> writes:
Michael> Hi, I have made a few corrections/improvements to the "de.po"
Michael> file. The problem is that currently the English words
Michael> "Graphics" and "Figure" are both mapped onto the German word
Michael> "Abbildung" which caus
Dekel Tsur wrote:
On Mon, Oct 28, 2002 at 02:28:20PM +0900, Rob Lahaye wrote:
If it complicates the code, it is OK to allow selecting both
\textwidth and \textheight for either the figure width or height.
I'm not a LaTeX guru; does every \foowidth have a corresponding \fooheight ?
(with foo is
1 - 100 of 597 matches
Mail list logo
