>> 2. i have problem with update flags - setting updateFlags = Update::Force
>> | Update::FitCursor;
>>is not enough to render properly scrollbar and begining of a document
>> in case graphics
>>is resized (it may be bug, see
>> http://bugzilla.lyx.org/show_bug.cgi?id=4829 ).
>>what
Pavel Sanda wrote:
now we need somehow to allow the user to assign picture to the existing group
and
i'm not sure how to proceed here. i see two possibilities:
1. modify how the context menu works, so we have dynamically created and shown list
of groups for each call of context menu. choosi
> now we need somehow to allow the user to assign picture to the existing group
> and
> i'm not sure how to proceed here. i see two possibilities:
>
> 1. modify how the context menu works, so we have dynamically created and
> shown list
>of groups for each call of context menu. choosing one
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Thursday 14 February 2002 4:23 pm, John Levon wrote:
>> perhaps even better would be to secretly store both the relative
>> and
Angus> absoluate
>> paths. That way the document then also has a chance of surviving a
>> "mv",
Angu
On Thursday 14 February 2002 4:23 pm, John Levon wrote:
> perhaps even better would be to secretly store both the relative and
absoluate
> paths. That way the document then also has a chance of surviving a "mv",
because
> we look at the absolute path after a failing relative path
I've thoug
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Thu, Feb 14, 2002 at 12:05:33PM +0100, Jean-Marc Lasgouttes
John> wrote:
>> I think insetgraphics should treat all file names as relative to
>> buffer directory.
John> definitely because then it also allows :
John> /home/moz/mypict
On Thu, Feb 14, 2002 at 12:05:33PM +0100, Jean-Marc Lasgouttes wrote:
> I think insetgraphics should treat all file names as relative to buffer
> directory.
definitely because then it also allows :
/home/moz/mypictures/picture.png
so both cases would be covered fine
perhaps even better would
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> I have a figure at:
Allan> ../common/new-banner.png
Allan> that I'm using in a document. PDFLaTeX is able to find and
Allan> render it but InsetGraphics complains with an error message
Allan> (Alert dialog) that the file either does
* Angus Leeming <[EMAIL PROTECTED]> [010920 13:07]:
> On Thursday 20 September 2001 10:17, Baruch Even wrote:
> > * Angus Leeming <[EMAIL PROTECTED]> [010920 12:11]:
> > > If I want to display a .xpm file (so no conversion is needed to display
> it),
> > > the file displays fine. But it's delete
On Friday 21 September 2001 15:47, John Levon wrote:
> On Fri, Sep 21, 2001 at 03:31:30PM +0100, Angus Leeming wrote:
>
> > It does not yet take account of MONOCHROME, GRAYSCALE or COLOR.
> >
> > I assume that this is an XpmAttribute that I can set when calling
>
> color_key + XpmColorKey
>
>
On Fri, Sep 21, 2001 at 03:31:30PM +0100, Angus Leeming wrote:
> It does not yet take account of MONOCHROME, GRAYSCALE or COLOR.
>
> I assume that this is an XpmAttribute that I can set when calling
color_key + XpmColorKey
you do know that libXpm has an extensive manual right ?
ftp.x.org
re
On Thursday 20 September 2001 10:17, Baruch Even wrote:
> * Angus Leeming <[EMAIL PROTECTED]> [010920 12:11]:
> > If I want to display a .xpm file (so no conversion is needed to display
it),
> > the file displays fine. But it's deleted from my working directory!
> >
> > If I need to convert
* Angus Leeming <[EMAIL PROTECTED]> [010920 12:11]:
> If I want to display a .xpm file (so no conversion is needed to display it),
> the file displays fine. But it's deleted from my working directory!
>
> If I need to convert an image from some other format to xpm, then the
> original is pr
Baruch Even wrote:
>
> On Thu, 16 Aug 2001, Garst R. Reese wrote:
>
> > Old-Graphics is dealing with them. Graphics can't find the figure
> > dimensions in the ps header.
>
> At this time, it doesn't even try. I'll handle that in the image loading
> code where it belongs.
Cool. Thanks,
Garst
On Thu, 16 Aug 2001, Garst R. Reese wrote:
> Baruch Even wrote:
> >
> > * Garst R. Reese <[EMAIL PROTECTED]> [010815 15:00]:
> > > Graphics does not understand a weird file name (Old-Graphics does).
> >
> > Care to give an example?
> >
> CadSoft eagle PCB software puts out eps files with exten
Baruch Even wrote:
>
> * Garst R. Reese <[EMAIL PROTECTED]> [010815 15:00]:
> > Graphics does not understand a weird file name (Old-Graphics does).
>
> Care to give an example?
>
CadSoft eagle PCB software puts out eps files with extensions like .cmp
.sol .drd
Old-Graphics is dealing with them.
* Garst R. Reese <[EMAIL PROTECTED]> [010815 15:00]:
> Graphics does not understand a weird file name (Old-Graphics does).
Care to give an example?
--
Baruch Even
http://baruch.ev-en.org/
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010725 17:21]:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> >> Yes, this is exactly what you should do. Inline/Display figure
> >> does not really make sense. That's what tables do, too.
>
> Baruch> Fine with me, simpler to code, ju
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010725 16:56]:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> Baruch> When FI has a non-inline graphics it will break the paragraph
> Baruch> it currently is in and will set the paragraph layout to add a
> Baruch> vertical space before
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010725 16:56]:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> Baruch> When FI has a non-inline graphics it will break the paragraph
> Baruch> it currently is in and will set the paragraph layout to add a
> Baruch> vertical space before
On 25-Jul-2001 Baruch Even wrote:
> Is my method in IG for non-inline mode acceptable at all?
Well I would say if it wouldn't we would have to change that for tabulars
too, as they now do the same thing ;)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
On 09-Oct-2000 Baruch Even wrote:
I'll add this after commiting my last changes to insettabular/text!
(if noone else beats me ;)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel
On Sun, 13 Aug 2000, Baruch Even wrote:
> Attached is a patch to fix the Clone() method of InsetGraphics, this fixes
> a bug that was introduced in the latest update to the inset.
I've applied this in my tree. Committing soon.
Allan. (ARRae)
On 4 Aug 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | Hello,
> |
> | Attached is a patch to add some configure magic that will by default
> | disable InsetGraphics and can be easily enabled with a
> | --enable-inset-graphics flag.
>
> I will not apply this.
On 4 Aug 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | Hello,
> |
> | Attached is a patch to add some configure magic that will by default
> | disable InsetGraphics and can be easily enabled with a
> | --enable-inset-graphics flag.
>
> I will not apply this.
Baruch Even <[EMAIL PROTECTED]> writes:
| Hello,
|
| Attached is a patch to add some configure magic that will by default
| disable InsetGraphics and can be easily enabled with a
| --enable-inset-graphics flag.
I will not apply this.
This is code that is supposed to compile and will also be th
On 31-Jul-2000 Baruch Even wrote:
> This is a second posting of the patch against the latest CVS, lars beat me
> with an commit after I created my former patch.
>
Applied!
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EM
Baruch Even <[EMAIL PROTECTED]> writes:
| On 31 Jul 2000, Jean-Marc Lasgouttes wrote:
|
| > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
| >
| > Baruch, I have problems compiling your code with compaq cxx (which is
| > very picky). I fixed some of them in cvs, but I am stuck with:
On 31 Jul 2000, Jean-Marc Lasgouttes wrote:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> Baruch, I have problems compiling your code with compaq cxx (which is
> very picky). I fixed some of them in cvs, but I am stuck with:
Oops, forgot about it, will work on it now, this is
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch, I have problems compiling your code with compaq cxx (which is
very picky). I fixed some of them in cvs, but I am stuck with:
cxx: Error: ../../../../lyx-devel/src/frontends/xforms/RadioButtonGroup.C, line 94:
namespace
On Mon, 31 Jul 2000, Juergen Vigna wrote:
> > Attached is my update for the InsetGraphics, this is a gzipped tar file
> > that includes a patch to be applied to the latest CVS source (unified
> > diff), and a set of files that are not currently existing in the
> > repository and should be added t
On 31-Jul-2000 Baruch Even wrote:
> Hello,
>
Hello Baruch!
> Attached is my update for the InsetGraphics, this is a gzipped tar file
> that includes a patch to be applied to the latest CVS source (unified
> diff), and a set of files that are not currently existing in the
> repository and shou
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch> It's rather hard to decide when to use relative dirs and when
Baruch> not to, currently I use solely relative dirs for ease of
Baruch> implementation, I've written this as a TODO/PROBLEM thing and
Baruch> will only bother really ta
Baruch Even <[EMAIL PROTECTED]> writes:
| I don't need full access to the whole lyx-devel, I only do the
| insetgraphics for now. If you prefer this way I can let you know of what
| files I touch regularly and you can set me up to change those (some are
| currently non-existent in the cvs reposit
On 17 Jul 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | I do not have cvs access so any commit will be in the form of a patch (and
> | added files) sent to someone who does have access.
>
> Hmm, da hmm... we(I) have not granted new people write access to the
>
Baruch Even <[EMAIL PROTECTED]> writes:
| What is the preferred policy on check-ins? specifically do you want me to
| submit a patch every time something has improved in the inset, or do you
| prefer to wait until it stabilizes itself and is actually useable before
| commiting anything into the r
Baruch Even <[EMAIL PROTECTED]> writes:
| but I will have time to play with lyx
| now).
Good.
| I need to know where to place the two classes GraphicsCache (and
| FormatConverter), I'd like to get on with them and put a skeleton up so
| that I'll be able to see how things go. Should I place it
On 13 Jul 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | The problem is that the dialog returns (to the best of my knowldege) only
> | absolute filenames. I can't think of a smart way, a dumb way could
> | possibly be to make everything below or in the same dir
Baruch Even <[EMAIL PROTECTED]> writes:
| The problem is that the dialog returns (to the best of my knowldege) only
| absolute filenames. I can't think of a smart way, a dumb way could
| possibly be to make everything below or in the same dir as the document
| relative and the rest absolute. I do
On 10 Jul 2000, Jean-Marc Lasgouttes wrote:
> > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>
> Baruch> On 8 Jul 2000, Lars Gullik Bjønnes wrote:
> >> | filename /tmp/platypus.png
>
> Baruch> Actually I've changed to use a relative file path. Now I've
> Baruch> got a problem dealing
On 07-Jul-2000 Baruch Even wrote:
> On Fri, 7 Jul 2000, Juergen Vigna wrote:
>
> Is there any reason why to do that instead of just a simple:
> \begin_inset Graphics
> filename /tmp/platypus.png
> rotate 0
> display monochrome
> ...
> \end_inset
>
Seems good for me!
> This way seems to me to
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
Baruch> On 8 Jul 2000, Lars Gullik Bjønnes wrote:
>> | filename /tmp/platypus.png
Baruch> Actually I've changed to use a relative file path. Now I've
Baruch> got a problem dealing with the clipart (which is fixed), but
Baruch> in most of
On 8 Jul 2000, Lars Gullik Bjønnes wrote:
> | filename /tmp/platypus.png
Actually I've changed to use a relative file path. Now I've got a problem
dealing with the clipart (which is fixed), but in most of the cases it
will be better to go relative.
--
Baruch Even
http://techst02.technion.ac
Baruch Even <[EMAIL PROTECTED]> writes:
| On Fri, 7 Jul 2000, Juergen Vigna wrote:
|
| > I use a xml near format, have a look at the new save format for
| > tabular-insets (just create one with the command tabular-inset-insert
| > and save that file).
|
| Is there any reason why to do that inst
On Fri, 7 Jul 2000, Juergen Vigna wrote:
> I use a xml near format, have a look at the new save format for
> tabular-insets (just create one with the command tabular-inset-insert
> and save that file).
Is there any reason why to do that instead of just a simple:
\begin_inset Graphics
filename /t
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>> Remember that we are moving away from being latex centered. Use a
>> fileformat that is easy to read and understand.
Baruch> Ok. I'll do that instead of an includegraphics like command,
Baruch> but I'll try to make sure it won't be too
On 07-Jul-2000 Lars Gullik Bjønnes wrote:
>
> Whatever you want... (stay in style with other insets)
>
I use a xml near format, have a look at the new save format for
tabular-insets (just create one with the command tabular-inset-insert
and save that file).
Jürgen
--
-._-._-._-._-._-.
On 7 Jul 2000, Lars Gullik Bjønnes wrote:
> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>
> | Yes (I mean it was not me, but I think so:). Would it be possible to
> | use the raw \includegraphics command as format? It would help reLyX a
> | lot. It would be nice too to be able to specify ra
Baruch Even <[EMAIL PROTECTED]> writes:
| As this is an inset it starts with a \begin_inset, I don't really think
| that changing that will be a good idea, though I can use the keyword
| includegraphics as the inset keyword instead of the current
| 'GRAPHICS'
What is wrong with 'GRAPHICS'?
(rena
On 7 Jul 2000, Jean-Marc Lasgouttes wrote:
> >> No it should just be possible to eventually read old figinsets
> >> format when we then use only the graphics-inset for this!
>
> Baruch> So you say that a 'read both old and new format, write new
> Baruch> format only' is the way to go?
>
> Yes (
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| Yes (I mean it was not me, but I think so:). Would it be possible to
| use the raw \includegraphics command as format? It would help reLyX a
| lot. It would be nice too to be able to specify raw includegraphics
| options (for special cases).
Re
On 07-Jul-2000 Baruch Even wrote:
>
> Hmpf, The inset actually has no idea of the dialog, it probably should use
> a signal with a this pointer to tell the dialog 'if you are working for
> me, then you're screwed too, hide yourself'
>
That's what I meant :)
>
> So you say that a 'read both o
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes:
>> No it should just be possible to eventually read old figinsets
>> format when we then use only the graphics-inset for this!
Baruch> So you say that a 'read both old and new format, write new
Baruch> format only' is the way to go?
Yes
On Fri, 7 Jul 2000, Juergen Vigna wrote:
> > 1. I'm using the GUIndependent code, and there is a show() method that is
>
> Have a look at the newly (today;) added src/frontends/xforms/FormCitation.C!
Will do.
> > 3. I hold a pointer to the inset (I clear it when I hide()), currently my
>
> I
On 7 Jul 2000, Lars Gullik Bjønnes wrote:
> Baruch Even <[EMAIL PROTECTED]> writes:
>
> | 2. I have the current scenario which I don't know how to handle:
> | a. User clicks on a graphics inset, the edit dialog opens.
> | b. User clicks in LyX on another graphics inset, it's edit dialog should
Juergen Vigna <[EMAIL PROTECTED]> writes:
| > 2. I have the current scenario which I don't know how to handle:
| > a. User clicks on a graphics inset, the edit dialog opens.
| > b. User clicks in LyX on another graphics inset, it's edit dialog should
| > open.
|
| No I think as it is with
Baruch Even <[EMAIL PROTECTED]> writes:
| The goals for the insetgraphics are to use the newer graphicx package in
| latex, call for the image conversions when exporting (like ExternalInset)
| be more robust than insetfig (the old figure inset) and possibly more
| feature rich.
Good.
| Currentl
Hello Baruch!
> The goals for the insetgraphics are to use the newer graphicx package in
Good!
> ... (smaller targets make for faster overall work) ...
True!
> Afterwards, I'll need to do the GraphicsCache and FormatConvertor
Ok! They should be general classes!
> 1. I'm using the GUIndepend
58 matches
Mail list logo
