Sure, the user can put it manually under "LaTeX options" but I think it
would be helpful to have a text box. This way, LyX could also display that
page instead of the first page.
Would this be difficult? My guess is that the text box would not be
difficult, but displaying the correct page would be
Enrico Forestieri wrote:
On Fri, May 29, 2009 at 11:12:18AM +0200, Helge Hafting wrote:
Graphichs dialog:
The "maintain aspect ratio" checkbox has the tooltip text "Scale image
to maximum size not exceeding width and height"
This looks like misinformation to me. I never had the impression tha
On Fri, May 29, 2009 at 11:12:18AM +0200, Helge Hafting wrote:
> Graphichs dialog:
> The "maintain aspect ratio" checkbox has the tooltip text "Scale image
> to maximum size not exceeding width and height"
>
> This looks like misinformation to me. I never had the impression that
> this checkbox
Graphichs dialog:
The "maintain aspect ratio" checkbox has the tooltip text "Scale image
to maximum size not exceeding width and height"
This looks like misinformation to me. I never had the impression that
this checkbox maximized the size in any way. It maintains correct aspect
ratio, for ex
Anders Ekberg wrote:
> Can someone please confirm this and whether it is only on Mac and I
> will file a bugzilla report if needed.
http://bugzilla.lyx.org/show_bug.cgi?id=3852
Jürgen
When opening the graphics dialog (by clicking on the graphics) for an
image with Set width defined. Alter the width and close the dialogue.
The next time a graphics dialog is opened the cursor is blinking in
the field with the width value (as it should), but the active field is
actually the
> Signal in the core, dialogs connect to that... makes 3 lines of code
> plus 1 per connecting dialog.
The problem is where to emit the signal. If I do that at the inset
level, and emit the signal whenever an inset is created, modified and
removed, it may not be efficient because insets get create
On Sat, Sep 15, 2007 at 01:55:24PM -0500, Bo Peng wrote:
> > I will commit if there is no objection.
>
> Done. I have only done this for InsetGraphics. Other insets like
> InsetExternal and InsetBibtex will wait.
>
> Now, the only problem left is when to update the embedding dialog. I
> am reluct
> I will commit if there is no objection.
Done. I have only done this for InsetGraphics. Other insets like
InsetExternal and InsetBibtex will wait.
Now, the only problem left is when to update the embedding dialog. I
am reluctant to implement a full auto-update facility, that update
this dialog w
RR(Debug::FILES) << " to "
- << params_.filename.toFilesystemEncoding() << std::endl;
- // FIXME: graphics dialog is not updated even if the underlying
- // filename is updated. What should I do?
+ params_.filename = file;
+ LYXERR(Debug::FILES) << &qu
> Sounds like a plan?
>
The attached patch:
1. Use EmbeddedFile for InsetGraphicsParams::filename. This involves
params2string and file format change.
2. Because InsetGraphics now has embedding information, it can be
easily updated from the embedding dialog. The inset graphic dialog now
has an e
> Attached is an updated patch, which is even uglier because it tries to
> display 'Embedded:/filename' in the graphic dialog when the file is
> embedded. As you can imagine, back and forth translations are needed.
I am actually waiting for someone to say ' this is way too ugly. Why
do not you mer
> Here is a question for you: Do you want to display true, embedded
> filename, or the may-not-exist external filename in the graphics
> dialog? The attached patch does the former, but in a ugly way:
>
Attached is an updated patch, which is even uglier because it tries to
displ
Here is a question for you: Do you want to display true, embedded
filename, or the may-not-exist external filename in the graphics
dialog? The attached patch does the former, but in a ugly way:
1. call updateDialog("graphics"); in setEmbed().
LFUN_INSET_DIALOG_UPDATE is triggered as ex
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
the attached makes it usable again...
Index: src/frontends/qt4/GuiGraphics.cpp
===
--- src/frontends/qt4/GuiGraphics.cpp (revision 20164)
+++ src/frontends/qt4/GuiGraphics.cpp (working copy)
@@ -217,12 +217,6 @@
}
-void GuiGraph
Richard Heck schrieb:
Attached is a diff for the related documentation.
Thanks, I put it in:
http://www.lyx.org/trac/changeset/17759
regards Uwe
I posted the fix for this.
Attached is a diff for the related documentation. Comments welcome.
Uwe Stöhr wrote:
> Hello Richard,
>
> there's a bug in you new code:
> Open the graphics dialog and check the scale option and the label
> "Scale Graphics %" gets red and
Richard
Uwe Stöhr wrote:
> Hello Richard,
>
> there's a bug in you new code:
> Open the graphics dialog and check the scale option and the label
> "Scale Graphics %" gets red and the "100" that was previously there
> disappears.
>
> regards Uwe
--
=
Hello Richard,
there's a bug in you new code:
Open the graphics dialog and check the scale option and the label "Scale Graphics %" gets red and
the "100" that was previously there disappears.
regards Uwe
Enrico Forestieri wrote:
>> - In my opinion when you want to set the height AND width the
>> keepaspectration option should be checked as default setting.
>
> I don't think so. If I explicitly set width AND height, I expect to get
> what I specify.
+1
Furthermore, I think that "maintain aspects
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> On Thu, Apr 05, 2007 at 12:14:46AM +0200, Uwe Stöhr wrote:
>> - In my opinion when you want to set the height AND width the
>> keepaspectration option should be checked as default setting.
Enrico> I don't think so. If I expli
On Thu, Apr 05, 2007 at 12:14:46AM +0200, Uwe Stöhr wrote:
> - In my opinion when you want to set the height AND width the
> keepaspectration option should be
> checked as default setting.
I don't think so. If I explicitly set width AND height, I expect to get
what I specify.
--
Enrico
> Here's the latest. Please test.
I tested this under Qt 4.2.2, so far it works as desired. I have only these
three things:
- When I set the scale factor explicitely to "100", dave the change and reopen the dialog this
setting is lost. This doesn't matter as the LaTeX code of this is the same
Enrico Forestieri wrote:
> On Wed, Apr 04, 2007 at 12:12:51PM -0400, Richard Heck wrote:
>
>> Here's the latest. Please test.
>>
> Works perfectly with Qt 4.1. A fine work, Richard.
>
Thanks much. I'll wait to see if I here from anyone else before committing.
Richard
--
=
On Wed, Apr 04, 2007 at 12:12:51PM -0400, Richard Heck wrote:
>
> Here's the latest. Please test.
Works perfectly with Qt 4.1. A fine work, Richard.
--
Enrico
Here's the latest. Please test.
Richard
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http:/
On Wed, Apr 04, 2007 at 05:36:10PM +0200, Abdelrazak Younes wrote:
> Richard Heck wrote:
> > Abdelrazak Younes wrote:
> >> Richard Heck wrote:
> >>> Attached are some screen shots of the new dialog, which I've updated on
> >>> the basis of the now restored old version. Comments welcome.
> >> Looks
Richard Heck wrote:
Abdelrazak Younes wrote:
Richard Heck wrote:
Attached are some screen shots of the new dialog, which I've updated on
the basis of the now restored old version. Comments welcome.
Looks good and better than what we have currently.
I miss some explanations for the "Set width
Enrico Forestieri wrote:
On Wed, Apr 04, 2007 at 03:16:44PM +0200, Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I've restored the horizontal layout now.
it is still not ok
Really? It's perfect on my screen... really weir
On Wed, Apr 04, 2007 at 03:16:44PM +0200, Abdelrazak Younes wrote:
> Edwin Leuven wrote:
> > Abdelrazak Younes wrote:
> >> Edwin Leuven wrote:
> >>> Abdelrazak Younes wrote:
> I've restored the horizontal layout now.
> >>>
> >>> it is still not ok
> >>
> >> Really? It's perfect on my screen...
Abdelrazak Younes wrote:
> Richard Heck wrote:
>> Attached are some screen shots of the new dialog, which I've updated on
>> the basis of the now restored old version. Comments welcome.
> Looks good and better than what we have currently.
>
> I miss some explanations for the "Set width" and "Set h
Richard Heck wrote:
Attached are some screen shots of the new dialog, which I've updated on
the basis of the now restored old version. Comments welcome.
Looks good and better than what we have currently.
I miss some explanations for the "Set width" and "Set height"
options... I don't know wh
Edwin Leuven wrote:
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I've restored the horizontal layout now.
it is still not ok
Really? It's perfect on my screen... really weird!
try to resize the dialog
Ah... yes, you're right! But the problem is more general...
Abdelrazak Younes wrote:
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I've restored the horizontal layout now.
it is still not ok
Really? It's perfect on my screen... really weird!
try to resize the dialog
Edwin Leuven wrote:
Abdelrazak Younes wrote:
I've restored the horizontal layout now.
it is still not ok
Really? It's perfect on my screen... really weird!
will commit a fix...
Fine.
Abdel.
Abdelrazak Younes wrote:
I've restored the horizontal layout now.
it is still not ok
will commit a fix...
Uwe Stöhr wrote:
> the bug introduced by 17625 and 17626 by reverting these
> changesets because 1) they introduced a bug and 2) they don't do what
> advertised, rather the contrary. I checked this both on Windows (with
> Qt4.1.4 and Qt4.2.2) and Solaris (with Qt4.2.2). See the attached
imag
Richard Heck wrote:
Enrico Forestieri wrote:
Please, can you wait with this patch? Before you commit it I would like
to see resolved the bug introduced by 17625 and 17626 by reverting these
changesets because 1) they introduced a bug and 2) they don't do what
advertised, rather the contrary. I c
> the bug introduced by 17625 and 17626 by reverting these
> changesets because 1) they introduced a bug and 2) they don't do what
> advertised, rather the contrary. I checked this both on Windows (with
> Qt4.1.4 and Qt4.2.2) and Solaris (with Qt4.2.2). See the attached images.
That's weird, what
Enrico Forestieri wrote:
Please, can you wait with this patch? Before you commit it I would like
to see resolved the bug introduced by 17625 and 17626 by reverting these
changesets because 1) they introduced a bug and 2) they don't do what
advertised, rather the contrary. I checked this both on W
On Tue, Apr 03, 2007 at 05:55:29PM -0400, Richard Heck wrote:
>
> Attached is what is hopefully the penultimate version of this patch.
> Please note that the diff was run from src/frontends/qt4/.
>
> The changes at the beginning of QGraphicsDialog.C are less extensive
> than they appear. I had to
Attached is what is hopefully the penultimate version of this patch.
Please note that the diff was run from src/frontends/qt4/.
The changes at the beginning of QGraphicsDialog.C are less extensive
than they appear. I had to re-arrange this so I could make sense of it.
The only real changes are ad
> are u sure it doesn't work with:
>
> QGraphicsDialog::on_Width_textChanged(const QString &)
Thanks, now I get it. Patch comes tomorrow.
regards Uwe
Uwe Stöhr wrote:
This is simple and logic. I wrote it down here in Pseudocode as I still
fail to implement this easy code in GraphicsDialog.C (I fail to manage
that QGraphicsDialog::on_Width_textChanged() is really called when the
text is changed - I' too stupid!).
are u sure it doesn't work
Here's my solution in Pseudocode:
void QGraphicsDialog::on_aspectration_toggled()
begin
// set the same unit for width and height
if Index(widthUnit) != Index(heightUnit) then
Index(heightUnit) = Index(widthUnit);
// only the smaller value is used by LaTeX when aspectratio is on
// therefor
Richard Heck schrieb:
Attached is a patch that PARTIALLY addresses this issue.
Hi Richard, I'm currently working on a different solution but needs a day for this as I'm new to Qt.
I'll send you something as soon it's ready (I hope tomorrow).
regards Uwe
Attached is a patch that PARTIALLY addresses this issue. I say
"partially" because the work is not complete. In particular, I HAVE NOT
CHECKED to make sure that the dialog actually works: That is, that if
you say "Scale 50%" you get the right LaTeX output. The changes made to
QGraphics::apply() ar
Discussion of bug 3215
http://bugzilla.lyx.org/show_bug.cgi?id=3215
revealed some problems with the current UI in the graphics dialog.
Attached is a screenshot of an idea for a new organization. The "Set
width" and "Set height" checkboxes are enabled only when "Sc
John Pye wrote:
Hi all
The following are some usability comments from my use of the LyX
Graphics dialog. It's not user-support stuff, so I'm hoping it's
appropriate to send it here. If these have been reported already, or
have even been fixed (I am using 1.4.3 in Ubuntu 6.10) p
Hi all
The following are some usability comments from my use of the LyX
Graphics dialog. It's not user-support stuff, so I'm hoping it's
appropriate to send it here. If these have been reported already, or
have even been fixed (I am using 1.4.3 in Ubuntu 6.10) please disregard.
Am Freitag, 3. November 2006 17:34 schrieb Leuven, E.:
> Kornel wrote:
> > Load a document with a figure which is _not_ displayed in lyx.
> > Go to graphics dialog->Extra options
> > Enable "Show in LyX"
> > ==> OK button remains gray.
>
> should w
Kornel wrote:
> Load a document with a figure which is _not_ displayed in lyx.
> Go to graphics dialog->Extra options
> Enable "Show in LyX"
> ==> OK button remains gray.
should work now...
> Load a document with a figure which is _not_ displayed in lyx.
> Go to graphics dialog->Extra options
> Enable "Show in LyX"
> ==> OK button remains gray.
thanks, will have a look...
Am Freitag, 3. November 2006 14:44 schrieb Leuven, E.:
> José wrote:
> > It seems to work for me.
> > I have tried to change an existing document and to insert a new figure.
> > It worked in both cases.
>
Load a document with a figure which is _not_ displayed in lyx
José wrote:
> It seems to work for me.
> I have tried to change an existing document and to insert a new figure.
> It worked in both cases.
thanks
On Friday 03 November 2006 11:36 am, Leuven, E. wrote:
> (would be nice if someone can try it out...)
It seems to work for me.
I have tried to change an existing document and to insert a new figure. It
worked in both cases.
--
José Abílio
From: José Matos [mailto:[EMAIL PROTECTED]
> If no one shouts until tomorrow you can put in.
it is in:
http://www.lyx.org/trac/changeset/15707
(would be nice if someone can try it out...)
José wrote:
> If no one shouts until tomorrow you can put in.
ok, will do...
On Thursday 02 November 2006 1:31 pm, Leuven, E. wrote:
> moreover, this way we avoid clutter on the dialog (presenting too many
> options at once) while having the main output options (the ones we care
> about most) on the first tab.
>
> i think this makes sense in a common use context, and i like
> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes:
Edwin> JML à dit:
>> Personally, I would put the "show in LyX" part at the bottom.
Edwin> i ended up putting it under the extra tab:
Excellent.
JMarc
On Wed, Nov 01, 2006 at 02:23:46PM +0100, Herbert Voss wrote:
> Enrico Forestieri schrieb:
[...]
> > Essentially, we should replace the converter from postscript to pdf
> > as follows:
> >
> > pspdf13 -dAutoRotatePages#/None $$i $$o
>
> why ps2pdf13??
> This is a regression. It should be ps2pdf,
> "Edwin" == Leuven, E <[EMAIL PROTECTED]> writes:
Edwin> (sorry for messing up the thread but i am on sucky ms webmail
Edwin> atm...) what about this then:
Edwin> http://leuven.ecodip.net/lyx/g.png
Edwin> only new layout + separate setting of scaling in output
Personally, I would put the "
(sorry for messing up the thread but i am on sucky ms webmail atm...)
what about this then:
http://leuven.ecodip.net/lyx/g.png
only new layout + separate setting of scaling in output
Enrico Forestieri schrieb:
> On Wed, Nov 01, 2006 at 09:34:30AM +0100, Georg Baum wrote:
>
>> Am Dienstag, 31. Oktober 2006 22:09 schrieb Enrico Forestieri:
>>> I am wondering if it is worth trying such a check when deciding whether
>>> ps2pdf or epstopdf is to be used, instead of defining a furth
On Wed, Nov 01, 2006 at 09:34:30AM +0100, Georg Baum wrote:
> Am Dienstag, 31. Oktober 2006 22:09 schrieb Enrico Forestieri:
> > I am wondering if it is worth trying such a check when deciding whether
> > ps2pdf or epstopdf is to be used, instead of defining a further pdf4
> format.
>
> How much
Georg Baum schrieb:
> Am Dienstag, 31. Oktober 2006 22:23 schrieb Herbert Voss:
>> ps2pdf _and_ epstopdf uses both ghostscript ...
>> sometimes ghostscript is too clever and rotates parts of the images,
>> which shouldn't. In this case a -dAutoRotatePages=/None did the trick.
>
> Yes. Adding that
Am Dienstag, 31. Oktober 2006 22:09 schrieb Enrico Forestieri:
> I am wondering if it is worth trying such a check when deciding whether
> ps2pdf or epstopdf is to be used, instead of defining a further pdf4
format.
How much work would that be? At the moment I tend to prefer the first
solution I
Am Dienstag, 31. Oktober 2006 22:23 schrieb Herbert Voss:
> ps2pdf _and_ epstopdf uses both ghostscript ...
> sometimes ghostscript is too clever and rotates parts of the images,
> which shouldn't. In this case a -dAutoRotatePages=/None did the trick.
Yes. Adding that as commandline option to ps2p
Georg Baum schrieb:
> Am Dienstag, 31. Oktober 2006 16:05 schrieb Enrico Forestieri:
>> On Tue, Oct 31, 2006 at 01:46:54PM +0100, Georg Baum wrote:
>>
>>> Enrico Forestieri wrote:
>>>
But I simply used the default converter chosen by LyX and the
> rotation
was actually depending on using
On Tue, Oct 31, 2006 at 09:31:26PM +0100, Georg Baum wrote:
> I see the same behaviour, but I don't agree with the solution. The problem
> here is that the image is detected by LyX as PS, not EPS, because the
> first line reads
>
> %!PS-Adobe-2.0
>
> and not
>
> %!PS-Adobe-2.0 EPSF-2.0
>
> T
Am Dienstag, 31. Oktober 2006 16:05 schrieb Enrico Forestieri:
> On Tue, Oct 31, 2006 at 01:46:54PM +0100, Georg Baum wrote:
>
> > Enrico Forestieri wrote:
> >
> > > But I simply used the default converter chosen by LyX and the
rotation
> > > was actually depending on using latex or pdflatex.
>
Michael Gerz wrote:
If this is the case, I don't like the new tabs. If a user inserts a new
graphics, he is more concerned about LaTeX output than about how his
graphics is shown in LyX. The dialog suggests the opposite.
I agree. The basic output settings (filename, size in the LaTeX
document
Leuven, E. wrote:
i reorganized the first tab as follows:
http://leuven.ecodip.net/lyx/g1.png
http://leuven.ecodip.net/lyx/g2.png
what do you think?
Do "Display" and "Scale(%)" refer to output in LyX? It's not really clear.
If this is the case, I don't like the new tabs. If a user inserts
On Tue, Oct 31, 2006 at 01:46:54PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > But I simply used the default converter chosen by LyX and the rotation
> > was actually depending on using latex or pdflatex.
>
> Then we might need to change the default converter. Do you have an exampl
Enrico Forestieri wrote:
> But I simply used the default converter chosen by LyX and the rotation
> was actually depending on using latex or pdflatex.
Then we might need to change the default converter. Do you have an example
file? I don't remember seeing this with the default converter.
> So, I
> Perhaps you could also think about separating the output "scale" from
> the "width" widget. I still find that very misleading and inconvenient.
ok, i'll have a look
On Tue, Oct 31, 2006 at 12:58:12PM +0100, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > On Tue, Oct 31, 2006 at 11:45:26AM +0100, Leuven, E. wrote:
> >
> >> Abdelrazak Younes wrote:
> >> > The rotation does not apply to the LyX display?
> >>
> >> yeah, it does (but i guess that this is sec
Enrico Forestieri wrote:
> On Tue, Oct 31, 2006 at 11:45:26AM +0100, Leuven, E. wrote:
>
>> Abdelrazak Younes wrote:
>> > The rotation does not apply to the LyX display?
>>
>> yeah, it does (but i guess that this is secondary)
Nevertheless it is confusing if one "output" setting does also influ
Leuven, E. wrote:
> what do you think?
I like it.
Perhaps you could also think about separating the output "scale" from
the "width" widget. I still find that very misleading and inconvenient.
Jürgen
On Tue, Oct 31, 2006 at 11:45:26AM +0100, Leuven, E. wrote:
> Abdelrazak Younes wrote:
> >> i reorganized the first tab as follows:
> >>
> >> http://leuven.ecodip.net/lyx/g1.png
> >> http://leuven.ecodip.net/lyx/g2.png
> >
> > The rotation does not apply to the LyX display?
>
> yeah, it does (bu
Leuven, E. wrote:
Abdelrazak Younes wrote:
i reorganized the first tab as follows:
http://leuven.ecodip.net/lyx/g1.png
http://leuven.ecodip.net/lyx/g2.png
The rotation does not apply to the LyX display?
yeah, it does (but i guess that this is secondary)
Is it really useful to have the rota
Abdelrazak Younes wrote:
>> i reorganized the first tab as follows:
>>
>> http://leuven.ecodip.net/lyx/g1.png
>> http://leuven.ecodip.net/lyx/g2.png
>
> The rotation does not apply to the LyX display?
yeah, it does (but i guess that this is secondary)
> If yes, then there's maybe a usability pro
Leuven, E. wrote:
hi guys,
atm the graphics dialog looks like this:
http://leuven.ecodip.net/lyx/g.png
i reorganized the first tab as follows:
http://leuven.ecodip.net/lyx/g1.png
http://leuven.ecodip.net/lyx/g2.png
The rotation does not apply to the LyX display?
what do you think?
If
hi guys,
atm the graphics dialog looks like this:
http://leuven.ecodip.net/lyx/g.png
i reorganized the first tab as follows:
http://leuven.ecodip.net/lyx/g1.png
http://leuven.ecodip.net/lyx/g2.png
what do you think?
ed.
On Tue, Apr 04, 2006 at 08:28:26PM +, Angus Leeming wrote:
> Georg Baum <[EMAIL PROTECTED]> writes:
> > Angus, you finally made me to fix this the dirty way I always wanted to
> > do it right by changing the return type of readBB_from_PSFile(), but now I
> > simply created a sane string.
> > T
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>> There is a bugzilla entry for that, but I do not remember it...
Georg> It is http://bugzilla.lyx.org/show_bug.cgi?id=1235, but I would
Georg> not be surprised if there was a duplicate.
I would think so, but I could not find it either.
Georg Baum wrote:
> It is http://bugzilla.lyx.org/show_bug.cgi?id=1235, but I would not be
> surprised if there was a duplicate.
I suspect this one:
http://bugzilla.lyx.org/show_bug.cgi?id=2211
Jürgen
Jean-Marc Lasgouttes wrote:
> You can commit it to 1.4.1svn too.
Done.
> There is a bugzilla entry for that, but I do not remember it...
It is http://bugzilla.lyx.org/show_bug.cgi?id=1235, but I would not be
surprised if there was a duplicate.
Georg
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> I removed readBB_lyxerrMessage because of your #warning. Since
Georg> I have no time right now I undid that change and will commit
Georg> the attached patch.
You can commit it to 1.4.1svn too.
There is a bugzilla entry for that, but
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
> | - if (contains(s,"%%BoundingBox:") && !contains(s,"atend")) {
> | - string const bb = ltrim(s.substr(14));
> | - readBB_lyxerrMessage(file_, zipped, bb);
> | + boost::s
Anand Rangarajan wrote:
> I tested the patch out on the trunk (lyx-1.5.0svn) build 13548. It works
> for me on a SUSE x86_64 box (Qt frontend). I removed the (.*) from the
> patch before compiling.
Fine.
> I tested it only on matlab produced eps files which have spaces in them.
> When I placed r
Georg Baum <[EMAIL PROTECTED]> writes:
>
> Am Dienstag, 4. April 2006 22:28 schrieb Angus Leeming:
> > The .* on the is rather ugly, no? Also, why put it in a group since you
> don't
> > appear to go on to use it.
>
> That was a copy/paste error. I will just remove it.
>
> Georg
>
>
I tested
Georg Baum <[EMAIL PROTECTED]> writes:
| Index: src/support/filetools.C
| ===
| --- src/support/filetools.C (Revision 13548)
| +++ src/support/filetools.C (Arbeitskopie)
| @@ -1168,21 +1157,40 @@ string const readBB_from_PSFile(st
Am Dienstag, 4. April 2006 22:28 schrieb Angus Leeming:
> The .* on the is rather ugly, no? Also, why put it in a group since you
don't
> appear to go on to use it.
That was a copy/paste error. I will just remove it.
Georg
Georg Baum <[EMAIL PROTECTED]> writes:
> Angus, you finally made me to fix this the dirty way I always wanted to
> do it right by changing the return type of readBB_from_PSFile(), but now I
> simply created a sane string.
> The attached works for me. I'll put it in trunk tomorrow if nobody objects
Angus Leeming wrote:
> Anand Rangarajan <[EMAIL PROTECTED]> writes:
>> How hard will it be to fix the source to read the bounding box entries
>> and account for the fact that there could be spaces. Anyone know the
>> actual source code that needs to be fixed? Is it in
>> src/graphics/GraphicsParam
1 - 100 of 418 matches
Mail list logo
