Re: graphics problems
On Sun, Jul 29, 2001 at 09:01:24AM +0300, Baruch Even wrote: If you want an immediate conversion to xpm, than both ImageMagick and netpbm can do that. Define a converter for imagemagick is to define a call to: convert $$i $$o Okay. Now here is what happens: [kayvan@camel ~]$ lyx /usr/share/lyx/doc/UserGuide.lyx convert: Unable to open file (mobius.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/mobius29265r4Vb3I.xpmFailed convert: Unable to open file (escher-lsd.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/escher-lsd29265f8LD1P.xpmFailed convert: Unable to open file (platypus.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/platypus292653bMioL.xpmFailed I don't have any tmpdir settings, but apparently the InsetGraphics stuff is attempting to write into the read-only document directory. Copying UserGuide.lyx and /usr/share/lyx/doc/*.eps to another directory and I run lyx again to get: [kayvan@camel /tmp/X]$ lyx UserGuide.lyx imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/mobius29288M3ippk.xpmFailed imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/escher-lsd29288gGbxU5.xpmFailed imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/platypus292887Buym8.xpmFailed So, what is happening now? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: graphics problems
* Garst R. Reese [EMAIL PROTECTED] [010729 09:40]: Baruch Even wrote: * Kayvan A. Sylvan [EMAIL PROTECTED] [010729 08:46]: On Sun, Jul 29, 2001 at 03:52:33AM +0100, John Levon wrote: On Sat, Jul 28, 2001 at 11:10:56PM -0300, Garst R. Reese wrote: I had a document with lots of .epsi files generated with ps2epsi or files in .eps format with other suffixes from eagle. Suddenly lyx is telling me that I am missing converters epsi to xpm, cmp to xpm, sol to xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. so if we haven't got a converter by name, we should determine file type by a magic approach instead. Baruch, I suppose you could use ImageMagick identify or something ? What packages are supposed to be installed for this to work? If you want an immediate conversion to xpm, than both ImageMagick and netpbm can do that. Define a converter for imagemagick is to define a call to: convert $$i $$o under netpbm: pstopnm $$i | pnmtoxpm $$o I will however write something to replace converter and that will do the rest of the stuff images need (rotations and such) Old-Graphic somehow detected the ps, eps, epsi files regardless of the suffix. My printed circuit board layout software puts out lots of files with suffixes like .cmp, .sol, .drd which are all eps files and this did not cause a problem. I have -lots- of these and it will be a real PITA if I have rename them all. Old-Graphics is simply assuming everything is eps and will load everything as eps, I'll change my patch to do something equivalent now, but it will be hacky! Check CVS as of now. What, BTW, is the use of Old-Graphics? Testing and comparing. Should I stop auto-converting Old to new for now? or are we better with this testing? -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
* Kayvan A. Sylvan [EMAIL PROTECTED] [010729 09:40]: On Sun, Jul 29, 2001 at 09:01:24AM +0300, Baruch Even wrote: If you want an immediate conversion to xpm, than both ImageMagick and netpbm can do that. Define a converter for imagemagick is to define a call to: convert $$i $$o Okay. Now here is what happens: [kayvan@camel ~]$ lyx /usr/share/lyx/doc/UserGuide.lyx convert: Unable to open file (mobius.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. I don't have any tmpdir settings, but apparently the InsetGraphics stuff is attempting to write into the read-only document directory. I thought I solved that... apparently not. Copying UserGuide.lyx and /usr/share/lyx/doc/*.eps to another directory and I run lyx again to get: [kayvan@camel /tmp/X]$ lyx UserGuide.lyx imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/mobius29288M3ippk.xpmFailed So, what is happening now? This is an error from the XPM loading functions of X11 (actually XPM library), the error means: ... If no color is found, and no close color exists or is wanted, and all visuals have been exhausted, XpmColorFailed is returned. It is possible that I didn't ask in there for close colors, will check that. It is however a limit on the colors your X11 provides, though I need to handle that more gracefully. -- Baruch Even http://baruch.ev-en.org/
GNOME frontend compile problem
Hi all, I'm having some more difficulty compiling the gnome frontend (without my new dialogs added). The error is as follows: (from lyxdevel/src) ==CUT== /bin/sh ../libtool --mode=link g++ -g -O -fno-exceptions -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o ColorHandler.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontInfo.o FontLoader.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o LyXSendto.o LyXView.o MenuBackend.o Painter.o PainterBase.o ParagraphParameters.o Sectioning.o Spacing.o TextCache.o ToolbarDefaults.o UpdateInset.o Variables.o WorkArea.o XFormsView.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o counters.o debug.o encoding.o exporter.o figure_form.o figureForm.o font.o gettext.o importer.o intl.o kbmap.o kbsequence.o language.o lastfiles.o layout.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxlex.o lyxlex_pimpl.o lyxlookup.o lyxrc.o lyxrow.o lyxserver.o lyxvc.o main.o minibuffer.o paragraph.o paragraph_pimpl.o print_form.o screen.o sp_spell.o tabular.o tabular-old.o tex-accent.o tex-strings.o texrow.o text.o text2.o tracer.o trans.o trans_mgr.o undo.o undo_funcs.o undostack.o vc-backend.o vspace.o mathed/libmathed.la insets/libinsets.la graphics/libgraphics.la frontends/libfrontends.la support/libsupport.la ../sigc++/libsigc.la -lforms -lXpm -lsigc -lpthread -L/usr/lib -rdynamic -L/usr/lib -L/usr/X11R6/lib -lsigc -lpthread -lgnomemm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lgdk_imlib -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lSM -lICE -liberty -lc -lm -L/usr/X11R6/lib -lX11 g++ -g -O -fno-exceptions -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o ColorHandler.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontInfo.o FontLoader.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o LyXSendto.o LyXView.o MenuBackend.o Painter.o PainterBase.o ParagraphParameters.o Sectioning.o Spacing.o TextCache.o ToolbarDefaults.o UpdateInset.o Variables.o WorkArea.o XFormsView.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o counters.o debug.o encoding.o exporter.o figure_form.o figureForm.o font.o gettext.o importer.o intl.o kbmap.o kbsequence.o language.o lastfiles.o layout.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxlex.o lyxlex_pimpl.o lyxlookup.o lyxrc.o lyxrow.o lyxserver.o lyxvc.o main.o minibuffer.o paragraph.o paragraph_pimpl.o print_form.o screen.o sp_spell.o tabular.o tabular-old.o tex-accent.o tex-strings.o texrow.o text.o text2.o tracer.o trans.o trans_mgr.o undo.o undo_funcs.o undostack.o vc-backend.o vspace.o -rdynamic -rdynamic -rdynamic -rdynamic mathed/.libs/libmathed.a insets/.libs/libinsets.a graphics/.libs/libgraphics.a frontends/.libs/libfrontends.a support/.libs/libsupport.a ../sigc++/.libs/libsigc.a -lforms -lXpm -lpthread -L/usr/lib -L/usr/X11R6/lib -lpthread /usr/lib/libgnomemm.so -lSM -lICE -lXi -lXext -lX11 -lm -ldl -lpthread -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -lpthread /usr/lib/libgtkmm.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdkmm.so -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm /usr/lib/libsigc.so -lpthread /usr/lib/libglade-gnome.so -lSM -lICE -lXi -lXext -lX11 -lm -ldl -lz /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl -ldl -lXi -lXext -lX11 -lm -lSM -lICE -ldl -lXi -lXext -lX11 -lm -lz -lm /usr/lib/libart_lgpl.so /usr/lib/libgdk_imlib.so -ldl -lSM -lICE /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 /usr/lib/libglib.so -ldl -lSM -lICE -liberty -lc -lm -lX11 frontends/.libs/libfrontends.a(Toolbar_pimpl.o): In function `Toolbar::Pimpl::set(bool)': /usr/include/g++-3/std/bastring.h:343: undefined reference to `fl_set_object_helper' collect2: ld returned 1 exit status make[2]: *** [lyx] Error 1 make[2]: Leaving directory `/home/michael/Programming/Lyx/lyx-devel/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/michael/Programming/Lyx/lyx-devel/src' make: *** [all-recursive-am] Error 2 ==CUT== That error is xforms related I
Re: graphics problems
Baruch Even wrote: What, BTW, is the use of Old-Graphics? Testing and comparing. Should I stop auto-converting Old to new for now? or are we better with this testing? Personally, I think that auto-converting Old to new is a really bad idea. In addition to screwing my files, it also seems to have done the same with the UG. There are already enought problems with reading old files. Garst
Re: GNOME frontend compile problem
* Michael Koziarski [EMAIL PROTECTED] [010729 10:07]: Hi all, I'm having some more difficulty compiling the gnome frontend (without my new dialogs added). The error is as follows: (from lyxdevel/src) ==CUT== ==CUT== Can you verify that this is the original file in CVS and not a modified one? -- Baruch Even http://baruch.ev-en.org/
[PATCH] InsetGraphics updates
Avoid auto-converting to InsetGraphics from InsetFig (Garst's request). Changed from GRAPHICS to Graphics. Changed lib/configure.m4 to convert epsi figures too. Please apply soon, the GRAPHICS to Graphics change means that the inset loading after saving doesnt work until it is applied. -- Baruch Even http://baruch.ev-en.org/
Re: Artwork
* Reinhard Stepanek [EMAIL PROTECTED] [010729 08:44]: Hi! It's maybe non of your urgent needs, but how about a polished version of the LyX-Logo. Take a look at http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork.html and feel free to use it! If you will need someone who draws some buttons too, don't hesitate to ask me... Polished version is great, can we have it waxed too? ;-) -- Baruch Even http://baruch.ev-en.org/
Re: GNOME frontend compile problem
Can you verify that this is the original file in CVS and not a modified one? Yep, I just refetched the whole lyx-devel module. Same problem, the only thing I can think of is a problem with xforms 0.89. Could that be it? Cheers -- | Michael Koziarski |Conventional wisdom is often | | Data Engineer, Linux user | long on convention and short | | Objectivist. | on wisdom -- | | http://www.koziarski.com| Warren E. Buffett, BRK.A |
Re: GNOME frontend compile problem
* Michael Koziarski [EMAIL PROTECTED] [010729 12:35]: Can you verify that this is the original file in CVS and not a modified one? Yep, I just refetched the whole lyx-devel module. Same problem, the only thing I can think of is a problem with xforms 0.89. Could that be it? It might be, try to compile with 0.88 As you said before, I do not have a problem on my machine with this and I'm using 0.89.5 -- Baruch Even http://baruch.ev-en.org/
Re: Comments on InsetGraphics
Dekel Tsur wrote:
On Sun, Jul 29, 2001 at 12:44:34AM +0300, Baruch Even wrote:
\scalebox{2}{\includegraphics{file.eps}}
or if you use graphicx, \includegraphics[scale=2]{file.eps}.
BTW, if you plan to use graphicx, you should let the user decide if he want
to use graphics or graphicx.
I'm using graphicx only, why would a user want to use graphics? (I can
think of when exporting and giving to others, but graphicx should be
present a.e. [almost everywhere - that is, everywhere besides a set of
measure zero]).
If you use psfrag.sty, you get different results when using
\includegraphics[scale=2]{file.eps}
and when using
\scalebox{2}{\includegraphics{file.eps}}
- the use of \scalebox gives a problem when you always
load package pstricks, because there is also a
\scalbox definined, but with different parameters.
- \scalebox is not the preferred command to resize
images, this should always be done with
\includegraphics[scale=XXX]{file}
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Re: [PATCH] InsetGraphics updates
On Sun, 29 Jul 2001, Baruch Even wrote: Please apply soon, the GRAPHICS to Graphics change means that the inset loading after saving doesnt work until it is applied. I'd love to if you send the patch. Thanks, Asger
Re: [PATCH] InsetGraphics updates
Sure, sure, couldn't you just read it off my mind... ah, never mind I'll send it anyway... * Asger K. Alstrup Nielsen [EMAIL PROTECTED] [010729 13:36]: On Sun, 29 Jul 2001, Baruch Even wrote: Please apply soon, the GRAPHICS to Graphics change means that the inset loading after saving doesnt work until it is applied. I'd love to if you send the patch. Thanks, Asger -- Baruch Even http://baruch.ev-en.org/ graphics.diff.gz
Re: [PATCH] InsetGraphics updates
On Sun, 29 Jul 2001, Baruch Even wrote: Sure, sure, couldn't you just read it off my mind... ah, never mind I'll send it anyway... I promise to practice that. After all, it would be fairly useful. Meanwhile, I'll applied the patch. Greets, Asger graphics.diff.gz
[PATCH] InsetGraphics updates #2
Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). The scale option is added to the horizontal part but affects both horizontal and vertical, bad UI, I know. Consider this a proof of concept, and if someone won't do the UI fix I'll do it some other time. -- Baruch Even http://baruch.ev-en.org/ ig2.diff.gz
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote: Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). Happily, let you know in 2h. Thanks, Garst
Re: 1.1.6fix3 build report (debian packages)
On Sat, Jul 28, 2001 at 07:25:52PM +0100, Jules Bean wrote: Secondly, probably less important, make distclean doesn't quite get you back to 'square one'. In my rules file I've added: EXTRA_CLEAN=development/lyx.spec sigc++/slot.h sigc++/object_slot.h \ snip I think I've gotten myself confused here. I think this *was* the case with 1.1.6fix2, but isn't with 1.1.6fix3. In 1.1.6fix2 the files I mentioned were not in the tar.gz, but were generated. They now do seem to be in the tar.gz, so it makes sense that distclean doesn't delete them. Apologies for the bandwidth waste ;) Jules
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote:
Adds the scale method as request by Michael.
Fixes the EPS detection part, non hacky revision (Garst please test).
Maybe missing an include.
cvs log attached.
Garst
Making all in insets
make[3]: Entering directory `/usr/local/garst/lyx-devel/src/insets'
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../
-I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c
insetgraphics.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem
/usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/insetgraphics.pp -c insetgraphics.C
insetgraphics.C: In function `bool unnamed::isEPS(const std::string)':
insetgraphics.C:539: `ifstream' undeclared (first use this function)
insetgraphics.C:539: (Each undeclared identifier is reported only once for each
function it appears in.)
insetgraphics.C:539: parse error before `(' token
insetgraphics.C:541: `ifs' undeclared (first use this function)
make[3]: *** [insetgraphics.lo] Error 1
Re: [PATCH] InsetGraphics updates #2
Garst R. Reese wrote: Baruch Even wrote: Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). Maybe missing an include. cvs log attached. Garst No, it needed using std::ifstream; compiling now. Garst
Re: Rename 666 to TEX
On Sun, Jul 29, 2001 at 02:32:00PM +0200, Asger K. Alstrup Nielsen wrote: Hi, The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? Greets, Asger I totally agree. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Rename 666 to TEX
Asger K. Alstrup Nielsen wrote: The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. HErbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: Rename 666 to TEX
Herbert Voss wrote: Asger K. Alstrup Nielsen wrote: The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. It goes away anyway. I like the 666, maybe the same people trying to ban Harry Potter will give lyx some publicity also :) Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. Baruch, I suppose you could use ImageMagick identify or something ? It might be possible, but then I need ImageMagick for everyone, I'll add epsi to my list of eps figures. ok, but this won't work for the other cases as I'm sure you know. But maybe asking users to define such converters when they are using admittedly weird file names is not too bad a thing. If you will commit the patch I've sent last night you won't be bothered maybe you should start talking to someone with global commit privileges :)) regards john -- I'd rather be rudely informed than politely left in the dark.
Re: graphics problems
On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: Should I stop auto-converting Old to new for now? or are we better with this testing? much better ... painful for Garst but hopefully it will become useful enough to stay for the first pre-release ! john -- I'd rather be rudely informed than politely left in the dark.
Re: GNOME frontend compile problem
On Sun, Jul 29, 2001 at 09:16:22PM +1200, Michael Koziarski wrote: I just refetched the whole lyx-devel module. Same problem, the only thing I can think of is a problem with xforms 0.89. Could that be it? afaics your problem seems to be that you have somewhere a forms.h header that is lying about the installed version. nm /path/to/libforms.a | grep fl_set_object_helper ? john -- I'd rather be rudely informed than politely left in the dark.
Re: graphics problems
John Levon wrote: On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. Baruch, I suppose you could use ImageMagick identify or something ? It might be possible, but then I need ImageMagick for everyone, I'll add epsi to my list of eps figures. ok, but this won't work for the other cases as I'm sure you know. But maybe asking users to define such converters when they are using admittedly weird file names is not too bad a thing. Who are you calling weird :) If you will commit the patch I've sent last night you won't be bothered maybe you should start talking to someone with global commit privileges :)) Did you commit mpanel.diff? It does seem to cure the problem. Garst
Re: graphics problems
John Levon wrote: On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: Should I stop auto-converting Old to new for now? or are we better with this testing? much better ... painful for Garst but hopefully it will become useful enough to stay for the first pre-release ! Are you telling me that 1.1.15 and 1.1.16 would not have displayed my weird files? Do you really think that relying on suffixes to determine file type was ever a good idea? What advantage do you see in auto-converting Old to new, and if they are autoconverted, what is the use Old-Graphics? Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 10:42:01AM -0300, Garst R. Reese wrote: Are you telling me that 1.1.15 and 1.1.16 would not have displayed my weird files? as a side effect of only supporting eps ... Do you really think that relying on suffixes to determine file type was ever a good idea? it's a *reasonable* idea. anyway it should work for you now. it's exactly things like this that needs user testing, so the developer can see what /other/ people do. It's all part of the pain of being a bleeding edge user :) What advantage do you see in auto-converting Old to new, they're not now if I read current CVS right ... john -- I'd rather be rudely informed than politely left in the dark.
Re: graphics problems
* John Levon [EMAIL PROTECTED] [010729 16:56]: On Sun, Jul 29, 2001 at 10:42:01AM -0300, Garst R. Reese wrote: What advantage do you see in auto-converting Old to new, they're not now if I read current CVS right ... Old Graphics can be created now and was left only as a testing tool (to test auto conversion), I think that my idea of allowing auto conversion override is the best bet for now. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
On Sun, Jul 29, 2001 at 04:43:57PM +0300, Baruch Even wrote: Garst asked for no auto-conversion and I commented the old InsetFig back, with permission from Lars I'll introduce a new temporary config keyword to disable auto-conversion and so it will be possible to disable it locally in case my code is broken and stops peoples from doing there work. makes sense I think Garst does help me check that my fix works for him, though I probably wouldn't have found about it unless I would have enabled IG for everyone so brutally. that was exactly my point :) john -- I'd rather be rudely informed than politely left in the dark.
Re: graphics problems
On Sun, Jul 29, 2001 at 10:30:20AM -0300, Garst R. Reese wrote: maybe you should start talking to someone with global commit privileges :)) Did you commit mpanel.diff? It does seem to cure the problem. I don't even have frontends/xforms right now. We have to wait for Asger, Lars, Angus or whoever to commit regards john -- I'd rather be rudely informed than politely left in the dark.
Re: graphics problems
* John Levon [EMAIL PROTECTED] [010729 16:36]: On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. Baruch, I suppose you could use ImageMagick identify or something ? It might be possible, but then I need ImageMagick for everyone, I'll add epsi to my list of eps figures. ok, but this won't work for the other cases as I'm sure you know. But maybe asking users to define such converters when they are using admittedly weird file names is not too bad a thing. I'm assuming for now that only EPS is used in such a wierd way, otherwise I'll implement file(1) functionality into LyX for image formats. Right now I'm looking only at a signature for EPS files which is usually at the very start of the file and so is not too much work, and is nothing more than what InsetFig does right now. If you will commit the patch I've sent last night you won't be bothered maybe you should start talking to someone with global commit privileges :)) I believe in a (local to lyx-*) god who hears all and sees all and has in his eternal wisdom the decision when to give or not to give permissions. Besides, peer-review (assuming it gets done) is not a bad thing. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
* John Levon [EMAIL PROTECTED] [010729 16:36]: On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: Should I stop auto-converting Old to new for now? or are we better with this testing? much better ... painful for Garst but hopefully it will become useful enough to stay for the first pre-release ! Garst asked for no auto-conversion and I commented the old InsetFig back, with permission from Lars I'll introduce a new temporary config keyword to disable auto-conversion and so it will be possible to disable it locally in case my code is broken and stops peoples from doing there work. Garst does help me check that my fix works for him, though I probably wouldn't have found about it unless I would have enabled IG for everyone so brutally. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
John Levon wrote: On Sun, Jul 29, 2001 at 10:30:20AM -0300, Garst R. Reese wrote: maybe you should start talking to someone with global commit privileges :)) Did you commit mpanel.diff? It does seem to cure the problem. I don't even have frontends/xforms right now. We have to wait for Asger, Lars, Angus or whoever to commit OK, but the ChangeLog got rejected here. Surprise surpise. Did you request a commit? Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 02:47:50PM +0100, John Levon wrote: What advantage do you see in auto-converting Old to new, they're not now if I read current CVS right ... Yup. UserGuide.lyx displays again. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote: Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). The scale option is added to the horizontal part but affects both horizontal and vertical, bad UI, I know. Consider this a proof of concept, and if someone won't do the UI fix I'll do it some other time. -- Baruch Even http://baruch.ev-en.org/ Name: ig2.diff.gz ig2.diff.gzType: unspecified type (application/octet-stream) Encoding: base64 Looks good here. Got all of weird filenames with no sweat. mathpanel patch also retested. Thanks much, Garst
Re: [PATCH] InsetGraphics updates #2
On Sun, Jul 29, 2001 at 02:42:48PM +0300, Baruch Even wrote: Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). The scale option is added to the horizontal part but affects both horizontal and vertical, bad UI, I know. Consider this a proof of concept, and if someone won't do the UI fix I'll do it some other time. Looking at the patch, it seems that if you have foo.epsi, lyx will try to convert it to foo.eps ... Also, why did you define epsi format in your previous patch ? One argument in Converter::Convert is the format of the from_file, so it can be used as follows: converters.Convert(..,foo.epsi,..., eps, pdf)
Re: graphics problems
On Sun, Jul 29, 2001 at 08:59:17AM +0300, Baruch Even wrote: * Kayvan A. Sylvan [EMAIL PROTECTED] [010729 08:56]: On Sun, Jul 29, 2001 at 02:20:13AM -0300, Garst R. Reese wrote: What do I need to do to get this to work? netpbm has pstopnm and ppmtoxpm, but pstopnm just runs ghostscript. Why go to xpm at all? Baruch, Can you provide the script/whatever is necessary to make the new Graphics inset work? We should also consider adding it to the lyx sources, somehow. I can easily provide the toxpm magic to convert, but this will be a temporary bandaid until I create my specialy customized ImageTransformer to do resize/dither/cropt/rotate of images on screen. Note that convert can do all these transformation. Also, if you are planing to use convert (which give you no library dependency), then use it with pipes, e.g. convert file.gif xpm:-
unimportant license issue
shouldn't we word the GPL exception as suggested here : http://www.gnu.org/licenses/gpl-faq.html#TOCWritingFSWithNFLibs ? thanks john -- I'd rather be rudely informed than politely left in the dark.
Mathed bug
Whenever I type 10^ I automatically get 10^{hc} where hc is something in
my mathed clipboard.
The same happens for _ (subscript)
When working in an hebrew document the entrance and exit from mathed is
reversed. When typed space I get out in the right side instead of the
left side of the formula. We probably need a function to handle exit
side to be called from insets to make this standard. It's pretty
annoying for hebrew texts.
--
Baruch Even
http://baruch.ev-en.org/
Re: graphics problems
* John Levon [EMAIL PROTECTED] [010729 19:02]: On Sun, Jul 29, 2001 at 04:43:57PM +0300, Baruch Even wrote: Garst does help me check that my fix works for him, though I probably wouldn't have found about it unless I would have enabled IG for everyone so brutally. that was exactly my point :) The result is simple, if noone submits bug reports against IG, I assume it is bugless and thus I can enable auto-conversion, and then bug reports flow in and I disable it :-) -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
* Dekel Tsur [EMAIL PROTECTED] [010729 19:02]: On Sun, Jul 29, 2001 at 08:59:17AM +0300, Baruch Even wrote: * Kayvan A. Sylvan [EMAIL PROTECTED] [010729 08:56]: On Sun, Jul 29, 2001 at 02:20:13AM -0300, Garst R. Reese wrote: What do I need to do to get this to work? netpbm has pstopnm and ppmtoxpm, but pstopnm just runs ghostscript. Why go to xpm at all? Baruch, Can you provide the script/whatever is necessary to make the new Graphics inset work? We should also consider adding it to the lyx sources, somehow. I can easily provide the toxpm magic to convert, but this will be a temporary bandaid until I create my specialy customized ImageTransformer to do resize/dither/cropt/rotate of images on screen. Note that convert can do all these transformation. Also, if you are planing to use convert (which give you no library dependency), then use it with pipes, e.g. convert file.gif xpm:- netpbm can do it also and can also do pipes. I will however first do it simply with files and than switch to pipes, I don't want to build a huge mountain before I test each part. -- Baruch Even http://baruch.ev-en.org/
Re: [PATCH] InsetGraphics updates #2
* Dekel Tsur [EMAIL PROTECTED] [010729 19:02]: On Sun, Jul 29, 2001 at 02:42:48PM +0300, Baruch Even wrote: Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). The scale option is added to the horizontal part but affects both horizontal and vertical, bad UI, I know. Consider this a proof of concept, and if someone won't do the UI fix I'll do it some other time. Looking at the patch, it seems that if you have foo.epsi, lyx will try to convert it to foo.eps ... The latest patch will avoid this since it will detect it to be an eps file and avoid converting it, the detectFormat function will return the same suffix and so the if (suffix == fmt_to_convert_to) return; will just return with no conversion. Also, why did you define epsi format in your previous patch ? One argument in Converter::Convert is the format of the from_file, so it can be used as follows: converters.Convert(..,foo.epsi,..., eps, pdf) gotcha, can you finally write doc strings for converter? Everytime I need to use it and want to know how to do something I need to read the goddamn code, and it's not that easy to follow. If you'll document it's features and how to use it I'll know how to use it better and will not need such hacks. -- Baruch Even http://baruch.ev-en.org/
Support for multi-colunm align
The amsmath align environment can have more than 2 columns:
\begin{align}
1 2 3 4\\
5 6 7 8
\end{align}
Is it hard to add support for this ?
Note that we don't know the number of columns in advance, so
mathed_parse_lines() should increase the number of columns in the inset when
it reads the first line.
Compilation with egcs-1.1.2
For long time, the CVS code cannot be compiled with egcs-1.1.2 due to the usage of boost/crc.hpp in lyxsum.C. Does this mean that egcs-1.1.2 is no longer supported ?
lyx1.1.6fix3 - tmp dir
is it intended that lyx creates an unused emty tmp-dir anyway, when the button in preferences for the tmp-dir is inactive? Herbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: graphics problems
On Sun, Jul 29, 2001 at 07:04:56PM +0300, Baruch Even wrote: Note that convert can do all these transformation. Also, if you are planing to use convert (which give you no library dependency), then use it with pipes, e.g. convert file.gif xpm:- netpbm can do it also and can also do pipes. I think that you can support only ImageMagick (at least at first) since 1) It is installed on most machines. 2) I don't know if netpbm can do what we need (for example, it seems that pstopnm do not work on EPS files). 3) If only netpbm is installed, it is still possible to write a shell script named 'convert' that will imitate the ImageMagick convert command using the netpbm commands.
bibtopic package and lyx1.1.6fix3
when in latex preamble a \usepackage{bibtopic}
appears, but no corresponding bibtopic command
in the text, bibtex is not run from lyx, though
there is a \nocite* command with a bibstyle and
filename.
also \usepackage{bibtopic} gives no output, when
running from within lyx. running the exported
tex-file makes no problem.
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Re: bibtopic package and lyx1.1.6fix3
Herbert Voss wrote:
also \usepackage{bibtopic} gives no output, when
running from within lyx. running the exported
tex-file makes no problem.
forget it, the answer was in Jürgend last mail
from today...
Herbert
description environment
would it be possible to make tab move to the definition part, rather than space ? This would be easier to use for entries with a space in the name bit ... thanks john -- I'd rather be rudely informed than politely left in the dark.
makecvs.log
Here's the latest. Garst Making all in insets make[3]: Entering directory `/usr/local/garst/lyx-devel/src/insets' /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c insetgraphicsParams.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/insetgraphicsParams.pp -c insetgraphicsParams.C insetgraphicsParams.C: In function `void unnamed::writeResize(std::ostream, const std::string, InsetGraphicsParams::Resize, double)': insetgraphicsParams.C:210: no match for `std::basic_ostreamchar, std::char_traitschar char' operator ../../src/commandtags.h:307: candidates are: std::ostream operator(std::ostream, kb_action) ../../src/lyxfont.h:415: std::ostream operator(std::ostream, LyXFont::FONT_MISC_STATE) ../../src/layout.h:550: std::ostream operator(std::ostream, LyXTextClass::PageSides) insetgraphicsParams.C:213: no match for `std::basic_ostreamchar, lots of these before it fails. Garst
Re: Rename 666 to TEX
On Sun, Jul 29, 2001 at 10:23:53AM -0300, Garst R. Reese wrote: Herbert Voss wrote: Asger K. Alstrup Nielsen wrote: The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. It goes away anyway. I like the 666, maybe the same people trying to ban Harry Potter will give lyx some publicity also :) Funny, but Im going to have to agree with the others. If someone does happen to see an open 666 inset, this'll give them a clue as to what it does. -Amir
Re: Rename 666 to TEX
On Sun, Jul 29, 2001 at 08:14:41PM -0400, Amir Karger wrote: On Sun, Jul 29, 2001 at 10:23:53AM -0300, Garst R. Reese wrote: Herbert Voss wrote: Asger K. Alstrup Nielsen wrote: The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. It goes away anyway. I like the 666, maybe the same people trying to ban Harry Potter will give lyx some publicity also :) Funny, but Im going to have to agree with the others. If someone does happen to see an open 666 inset, this'll give them a clue as to what it does. Yes, the name of program features should be primarily influenced by clarity and intuitiveness. Whie 666 inset is clever and it makes sense within the sub-culture of people who know that ERT means Evil Red Text which is a reference to TeX mode, it fails on both clarity and intuitiveness. Too many in-jokes and obscure references. The TeX inset on the other hand, is clear and intuitive. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Purify #6
On Mon, Jul 23, 2001 at 11:45:30PM +0200, Michael Schmitt wrote: Hi, another bug report... I just realized a great way for Michael to test mathed with Purify. Andre, could you send him the equation-only version of my doctoral dissertation that I sent you? That doc is *really* heavy-duty mathed, and should scare up many lurking leaks. -- John Weiss Not through coercion. Not by force. But by compassion. By affection. And, a small fish. -His Holiness, the 14th Dalai Lama
Re: Artwork
On Sun, 29 Jul 2001, Reinhard Stepanek wrote: Hi! It's maybe non of your urgent needs, but how about a polished version of the LyX-Logo. Take a look at http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork.html and feel free to use it! If you will need someone who draws some buttons too, don't hesitate to ask me... This is sexy but what would be really nice is if the logo actually looked like something. The LyX creature is usually described as a deformed platypus. It'd be nice it actually looked like it could be a real creature -- with a beak that isn't just a cariciture. Anyway, what you've done does look very nice. If you feel inspired enough to transform the creature into a three dimensional being then I'm sure it'd look even better. In the meantime I think I might make use of it on our website. Allan. (ARRae)
Re: Rename 666 to TEX
On Sun, 29 Jul 2001, Kayvan A. Sylvan wrote: On Sun, Jul 29, 2001 at 08:14:41PM -0400, Amir Karger wrote: On Sun, Jul 29, 2001 at 10:23:53AM -0300, Garst R. Reese wrote: Herbert Voss wrote: Asger K. Alstrup Nielsen wrote: The 666 name is fun, but not very intuitive/informative. What about changing it to TEX? Failing that, we should at least use ERT, which is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. It goes away anyway. I like the 666, maybe the same people trying to ban Harry Potter will give lyx some publicity also :) Interesting publicity opportunity... Funny, but Im going to have to agree with the others. If someone does happen to see an open 666 inset, this'll give them a clue as to what it does. Yes, the name of program features should be primarily influenced by clarity and intuitiveness. Whie 666 inset is clever and it makes sense within the sub-culture of people who know that ERT means Evil Red Text which is a reference to TeX mode, it fails on both clarity and intuitiveness. Too many in-jokes and obscure references. The TeX inset on the other hand, is clear and intuitive. In a DocBook document TeX won't make much sense. On the other hand Raw may make more sense when used in both LaTeX and DocBook documents. You could also just call it a Markup inset since LaTeX and DocBook are markup languages. Allan. (ARRae)
Re: Artwork
On Mon, Jul 30, 2001 at 03:32:48PM +1000, Allan Rae wrote: http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork.html and feel free to use it! If you will need someone who draws some buttons too, don't hesitate to ask me... This is sexy but what would be really nice is if the logo actually looked like something. The LyX creature is usually described as a deformed platypus. It'd be nice it actually looked like it could be a real creature -- with a beak that isn't just a cariciture. Hey! I *like* the LyX creature as is. The fact that it is a semi-random collection of geometric shapes gives it a very unique look. There are camels and cats and dogs and ostriches everywhere, but none of them comes close to the unforgettable LyX creature. ;-) -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Purify #6
On Sun, 29 Jul 2001, John Weiss wrote: On Mon, Jul 23, 2001 at 11:45:30PM +0200, Michael Schmitt wrote: Hi, another bug report... I just realized a great way for Michael to test mathed with Purify. Andre, could you send him the equation-only version of my doctoral dissertation that I sent you? That doc is *really* heavy-duty mathed, and should scare up many lurking leaks. Michael, you could also grab the scary_eqns.lyx file out of: http://www.devel.lyx.org/~rae/QAUUG_rae.tar.gz as it has plenty of different equations you can test with -- the fourth equation seemed to be triggering problems when I lasted checked (about two weeks ago). Allan. (ARRae)
What version of XPM to use?
I have a Sun Solaris system where the libraries are not necessarily the most recent... Here's what happens with the latest CVS: g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -I/remote/tools/ksylvan/include -I/remote/tools/ksylvan/include/X11 -isystem /usr/openwin/include -O2 -isystem /depot/X11/include -W -Wall -Wp,-MD,.deps/ImageLoaderXPM.pp -c ImageLoaderXPM.C ImageLoaderXPM.C:65: warning: #warning This might be a dirty thing, but I dont know any other solution. ImageLoaderXPM.C: In method `enum ImageLoader::Result ImageLoaderXPM::runImageLoader(const string )': ImageLoaderXPM.C:73: `XpmAllocColor' undeclared (first use this function) ImageLoaderXPM.C:73: (Each undeclared identifier is reported only once ImageLoaderXPM.C:73: for each function it appears in.) make[2]: *** [ImageLoaderXPM.lo] Error 1 What should I do here? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | crown of her husband | Robin Gregory (2/28/92)
Re: Artwork
Allan Rae wrote: This is sexy but what would be really nice is if the logo actually looked like something. The LyX creature is usually described as a deformed platypus. It'd be nice it actually looked like it could be a real creature -- with a beak that isn't just a cariciture. Anyway, what you've done does look very nice. If you feel inspired enough to transform the creature into a three dimensional being then I'm sure it'd look even better. In the meantime I think I might make use of it on our website. Allan. (ARRae) The refined image takes 256 colors, 254 unique, lyx.xpm uses 7. That could be an issue for people using 8 bit color. I would like to see some of the buttons. Garst
Re: Artwork
On Sun, 29 Jul 2001, Kayvan A. Sylvan wrote: On Mon, Jul 30, 2001 at 03:32:48PM +1000, Allan Rae wrote: http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork.html and feel free to use it! Actually, Reinhard, what would be really helpful is if you could regenerate the logo to match the blue on the LyX website: #4669ad That is, for a blue background instead of a white or green one. Thanks, Allan. (ARRae)
Re: graphics problems
On Sun, Jul 29, 2001 at 09:01:24AM +0300, Baruch Even wrote: > If you want an immediate conversion to xpm, than both ImageMagick and > netpbm can do that. > > Define a converter for imagemagick is to define a call to: > convert $$i $$o Okay. Now here is what happens: [kayvan@camel ~]$ lyx /usr/share/lyx/doc/UserGuide.lyx convert: Unable to open file (mobius.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/mobius29265r4Vb3I.xpmFailed convert: Unable to open file (escher-lsd.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/escher-lsd29265f8LD1P.xpmFailed convert: Unable to open file (platypus.xpm) [Permission denied]. imageConverted, status=1 Loading XPM Image... No XPM file found. Loading /tmp/lyx_tmpdir29265GqMDJW/platypus292653bMioL.xpmFailed I don't have any tmpdir settings, but apparently the InsetGraphics stuff is attempting to write into the read-only document directory. Copying UserGuide.lyx and /usr/share/lyx/doc/*.eps to another directory and I run lyx again to get: [kayvan@camel /tmp/X]$ lyx UserGuide.lyx imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/mobius29288M3ippk.xpmFailed imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/escher-lsd29288gGbxU5.xpmFailed imageConverted, status=1 Loading XPM Image... Error reading XPM file 'XpmColorFailed Loading /tmp/lyx_tmpdir29288oOET6f/platypus292887Buym8.xpmFailed So, what is happening now? ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: graphics problems
* Garst R. Reese <[EMAIL PROTECTED]> [010729 09:40]: > Baruch Even wrote: > > > > * Kayvan A. Sylvan <[EMAIL PROTECTED]> [010729 08:46]: > > > On Sun, Jul 29, 2001 at 03:52:33AM +0100, John Levon wrote: > > > > On Sat, Jul 28, 2001 at 11:10:56PM -0300, Garst R. Reese wrote: > > > > > > > > > I had a document with lots of .epsi files generated with ps2epsi or > > > > > files in .eps format with other suffixes from eagle. Suddenly lyx is > > > > > telling me that I am missing converters epsi to xpm, cmp to xpm, sol to > > > > > xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. > > > > > > > > so if we haven't got a converter by name, we should determine file type > > > > by a magic approach instead. > > > > > > > > Baruch, I suppose you could use ImageMagick identify or something ? > > > > > > What packages are supposed to be installed for this to work? > > > > If you want an immediate conversion to xpm, than both ImageMagick and > > netpbm can do that. > > > > Define a converter for imagemagick is to define a call to: > > convert $$i $$o > > > > under netpbm: > > pstopnm $$i | pnmtoxpm > $$o > > > > I will however write something to replace converter and that will do the > > rest of the stuff images need (rotations and such) > Old-Graphic somehow detected the ps, eps, epsi files regardless of the > suffix. > My printed circuit board layout software puts out lots of files with > suffixes like .cmp, .sol, .drd which are all eps files and this did > not cause a problem. > I have -lots- of these and it will be a real PITA if I have rename them > all. Old-Graphics is simply assuming everything is eps and will load everything as eps, I'll change my patch to do something equivalent now, but it will be hacky! Check CVS as of now. > What, BTW, is the use of Old-Graphics? Testing and comparing. Should I stop auto-converting Old to new for now? or are we better with this testing? -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
* Kayvan A. Sylvan <[EMAIL PROTECTED]> [010729 09:40]: > On Sun, Jul 29, 2001 at 09:01:24AM +0300, Baruch Even wrote: > > If you want an immediate conversion to xpm, than both ImageMagick and > > netpbm can do that. > > > > Define a converter for imagemagick is to define a call to: > > convert $$i $$o > > Okay. Now here is what happens: > > [kayvan@camel ~]$ lyx /usr/share/lyx/doc/UserGuide.lyx > convert: Unable to open file (mobius.xpm) [Permission denied]. > imageConverted, status=1 > Loading XPM Image... No XPM file found. > > I don't have any tmpdir settings, but apparently the InsetGraphics stuff > is attempting to write into the read-only document directory. I thought I solved that... apparently not. > Copying UserGuide.lyx and /usr/share/lyx/doc/*.eps to another directory > and I run lyx again to get: > > [kayvan@camel /tmp/X]$ lyx UserGuide.lyx > imageConverted, status=1 > Loading XPM Image... Error reading XPM file 'XpmColorFailed > Loading /tmp/lyx_tmpdir29288oOET6f/mobius29288M3ippk.xpmFailed > > So, what is happening now? This is an error from the XPM loading functions of X11 (actually XPM library), the error means: "... If no color is found, and no close color exists or is wanted, and all visuals have been exhausted, XpmColorFailed is returned." It is possible that I didn't ask in there for close colors, will check that. It is however a limit on the colors your X11 provides, though I need to handle that more gracefully. -- Baruch Even http://baruch.ev-en.org/
GNOME frontend compile problem
Hi all, I'm having some more difficulty compiling the gnome frontend (without my new dialogs added). The error is as follows: (from lyxdevel/src) ==CUT== /bin/sh ../libtool --mode=link g++ -g -O -fno-exceptions -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o ColorHandler.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontInfo.o FontLoader.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o LyXSendto.o LyXView.o MenuBackend.o Painter.o PainterBase.o ParagraphParameters.o Sectioning.o Spacing.o TextCache.o ToolbarDefaults.o UpdateInset.o Variables.o WorkArea.o XFormsView.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o counters.o debug.o encoding.o exporter.o figure_form.o figureForm.o font.o gettext.o importer.o intl.o kbmap.o kbsequence.o language.o lastfiles.o layout.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxlex.o lyxlex_pimpl.o lyxlookup.o lyxrc.o lyxrow.o lyxserver.o lyxvc.o main.o minibuffer.o paragraph.o paragraph_pimpl.o print_form.o screen.o sp_spell.o tabular.o tabular-old.o tex-accent.o tex-strings.o texrow.o text.o text2.o tracer.o trans.o trans_mgr.o undo.o undo_funcs.o undostack.o vc-backend.o vspace.o mathed/libmathed.la insets/libinsets.la graphics/libgraphics.la frontends/libfrontends.la support/libsupport.la ../sigc++/libsigc.la -lforms -lXpm -lsigc -lpthread -L/usr/lib -rdynamic -L/usr/lib -L/usr/X11R6/lib -lsigc -lpthread -lgnomemm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lgtkmm -lgdkmm -lgtk -lgdk -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm -lsigc -lpthread -rdynamic -L/usr/lib -L/usr/X11R6/lib -lglade-gnome -lglade -lxml -lz -lgnomeui -lart_lgpl -lgdk_imlib -lSM -lICE -lgtk -lgdk -lgmodule -lXi -lXext -lX11 -lgnome -lgnomesupport -lesd -laudiofile -lm -ldb1 -lglib -ldl -lSM -lICE -liberty -lc -lm -L/usr/X11R6/lib -lX11 g++ -g -O -fno-exceptions -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o ColorHandler.o CutAndPaste.o DepTable.o FloatList.o Floating.o FontInfo.o FontLoader.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o LyXSendto.o LyXView.o MenuBackend.o Painter.o PainterBase.o ParagraphParameters.o Sectioning.o Spacing.o TextCache.o ToolbarDefaults.o UpdateInset.o Variables.o WorkArea.o XFormsView.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o counters.o debug.o encoding.o exporter.o figure_form.o figureForm.o font.o gettext.o importer.o intl.o kbmap.o kbsequence.o language.o lastfiles.o layout.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxlex.o lyxlex_pimpl.o lyxlookup.o lyxrc.o lyxrow.o lyxserver.o lyxvc.o main.o minibuffer.o paragraph.o paragraph_pimpl.o print_form.o screen.o sp_spell.o tabular.o tabular-old.o tex-accent.o tex-strings.o texrow.o text.o text2.o tracer.o trans.o trans_mgr.o undo.o undo_funcs.o undostack.o vc-backend.o vspace.o -rdynamic -rdynamic -rdynamic -rdynamic mathed/.libs/libmathed.a insets/.libs/libinsets.a graphics/.libs/libgraphics.a frontends/.libs/libfrontends.a support/.libs/libsupport.a ../sigc++/.libs/libsigc.a -lforms -lXpm -lpthread -L/usr/lib -L/usr/X11R6/lib -lpthread /usr/lib/libgnomemm.so -lSM -lICE -lXi -lXext -lX11 -lm -ldl -lpthread -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm -lpthread /usr/lib/libgtkmm.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdkmm.so -ldl -lXi -lXext -lX11 -lm -ldl -lXi -lXext -lX11 -lm -ldl -ldl -lXi -lXext -lX11 -lm /usr/lib/libsigc.so -lpthread /usr/lib/libglade-gnome.so -lSM -lICE -lXi -lXext -lX11 -lm -ldl -lz /usr/lib/libglade.so -ldl -lXi -lXext -lX11 -lm -lz /usr/lib/libxml.so -lz -lz -lz /usr/lib/libgnomeui.so -lm -lm -ldl -ldl -lXi -lXext -lX11 -lm -lSM -lICE -ldl -lXi -lXext -lX11 -lm -lz -lm /usr/lib/libart_lgpl.so /usr/lib/libgdk_imlib.so -ldl -lSM -lICE /usr/lib/libgtk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgdk.so -ldl -lXi -lXext -lX11 -lm /usr/lib/libgmodule.so -ldl -lXi -lXext -lX11 /usr/lib/libgnome.so -lm -ldl -lz -lm /usr/lib/libgnomesupport.so -lz -lm /usr/lib/libesd.so -lm -lm /usr/lib/libaudiofile.so -lm -lm -lm -ldb1 /usr/lib/libglib.so -ldl -lSM -lICE -liberty -lc -lm -lX11 frontends/.libs/libfrontends.a(Toolbar_pimpl.o): In function `Toolbar::Pimpl::set(bool)': /usr/include/g++-3/std/bastring.h:343: undefined reference to `fl_set_object_helper' collect2: ld returned 1 exit status make[2]: *** [lyx] Error 1 make[2]: Leaving directory `/home/michael/Programming/Lyx/lyx-devel/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/michael/Programming/Lyx/lyx-devel/src' make: *** [all-recursive-am] Error 2 ==CUT== That error is xforms related I
Re: graphics problems
Baruch Even wrote: > > > What, BTW, is the use of Old-Graphics? > > Testing and comparing. > > Should I stop auto-converting Old to new for now? or are we better with > this testing? Personally, I think that auto-converting Old to new is a really bad idea. In addition to screwing my files, it also seems to have done the same with the UG. There are already enought problems with reading old files. Garst
Re: GNOME frontend compile problem
* Michael Koziarski <[EMAIL PROTECTED]> [010729 10:07]: > Hi all, > > I'm having some more difficulty compiling the gnome frontend (without > my new dialogs added). The error is as follows: (from lyxdevel/src) > > ==CUT== > ==CUT== Can you verify that this is the original file in CVS and not a modified one? -- Baruch Even http://baruch.ev-en.org/
[PATCH] InsetGraphics updates
Avoid auto-converting to InsetGraphics from InsetFig (Garst's request). Changed from GRAPHICS to Graphics. Changed lib/configure.m4 to convert epsi figures too. Please apply soon, the GRAPHICS to Graphics change means that the inset loading after saving doesnt work until it is applied. -- Baruch Even http://baruch.ev-en.org/
Re: Artwork
* Reinhard Stepanek <[EMAIL PROTECTED]> [010729 08:44]: > Hi! > > It's maybe non of your urgent needs, but how about a "polished" version of > the LyX-Logo. Take a look at > > http://mailbox.univie.ac.at/Reinhard.Stepanek/lyx/lyx_artwork.html > > and feel free to use it! > If you will need someone who draws some buttons too, don't hesitate to ask > me... Polished version is great, can we have it waxed too? ;-) -- Baruch Even http://baruch.ev-en.org/
Re: GNOME frontend compile problem
> Can you verify that this is the original file in CVS and not a modified > one? Yep, I just refetched the whole lyx-devel module. Same problem, the only thing I can think of is a problem with xforms 0.89. Could that be it? Cheers -- | Michael Koziarski |"Conventional wisdom is often | | Data Engineer, Linux user | long on convention and short | | & Objectivist. | on wisdom" -- | | http://www.koziarski.com| Warren E. Buffett, BRK.A |
Re: GNOME frontend compile problem
* Michael Koziarski <[EMAIL PROTECTED]> [010729 12:35]: > > Can you verify that this is the original file in CVS and not a modified > > one? > Yep, > > I just refetched the whole lyx-devel module. Same problem, the only > thing I can think of is a problem with xforms 0.89. Could that be it? It might be, try to compile with 0.88 As you said before, I do not have a problem on my machine with this and I'm using 0.89.5 -- Baruch Even http://baruch.ev-en.org/
Re: Comments on InsetGraphics
Dekel Tsur wrote:
>
> On Sun, Jul 29, 2001 at 12:44:34AM +0300, Baruch Even wrote:
> > > \scalebox{2}{\includegraphics{file.eps}}
> > >
> > > or if you use graphicx, \includegraphics[scale=2]{file.eps}.
> > >
> > > BTW, if you plan to use graphicx, you should let the user decide if he want
> > > to use graphics or graphicx.
> >
> > I'm using graphicx only, why would a user want to use graphics? (I can
> > think of when exporting and giving to others, but graphicx should be
> > present a.e. [almost everywhere - that is, everywhere besides a set of
> > measure zero]).
>
> If you use psfrag.sty, you get different results when using
> \includegraphics[scale=2]{file.eps}
> and when using
> \scalebox{2}{\includegraphics{file.eps}}
- the use of \scalebox gives a problem when you always
load package pstricks, because there is also a
\scalbox definined, but with different parameters.
- \scalebox is not the preferred command to resize
images, this should always be done with
\includegraphics[scale=XXX]{file}
Herbert
--
http://www.educat.hu-berlin.de/~voss/lyx/
Re: [PATCH] InsetGraphics updates
On Sun, 29 Jul 2001, Baruch Even wrote: > Please apply soon, the GRAPHICS to Graphics change means that the inset > loading after saving doesnt work until it is applied. I'd love to if you send the patch. Thanks, Asger
Re: [PATCH] InsetGraphics updates
Sure, sure, couldn't you just read it off my mind... ah, never mind I'll send it anyway... * Asger K. Alstrup Nielsen <[EMAIL PROTECTED]> [010729 13:36]: > On Sun, 29 Jul 2001, Baruch Even wrote: > > > Please apply soon, the GRAPHICS to Graphics change means that the inset > > loading after saving doesnt work until it is applied. > > I'd love to if you send the patch. > > Thanks, > > Asger > > -- Baruch Even http://baruch.ev-en.org/ graphics.diff.gz
Re: [PATCH] InsetGraphics updates
On Sun, 29 Jul 2001, Baruch Even wrote: > Sure, sure, couldn't you just read it off my mind... ah, never mind I'll > send it anyway... I promise to practice that. After all, it would be fairly useful. Meanwhile, I'll applied the patch. Greets, Asger graphics.diff.gz
[PATCH] InsetGraphics updates #2
Adds the scale method as request by Michael. Fixes the EPS detection part, non hacky revision (Garst please test). The scale option is added to the horizontal part but affects both horizontal and vertical, bad UI, I know. Consider this a proof of concept, and if someone won't do the UI fix I'll do it some other time. -- Baruch Even http://baruch.ev-en.org/ ig2.diff.gz
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote: > > Adds the scale method as request by Michael. > Fixes the EPS detection part, non hacky revision (Garst please test). Happily, let you know in 2h. Thanks, Garst
Re: 1.1.6fix3 build report (debian packages)
On Sat, Jul 28, 2001 at 07:25:52PM +0100, Jules Bean wrote: > Secondly, probably less important, make distclean doesn't quite get > you back to 'square one'. In my rules file I've added: > > EXTRA_CLEAN=development/lyx.spec sigc++/slot.h sigc++/object_slot.h \ I think I've gotten myself confused here. I think this *was* the case with 1.1.6fix2, but isn't with 1.1.6fix3. In 1.1.6fix2 the files I mentioned were not in the tar.gz, but were generated. They now do seem to be in the tar.gz, so it makes sense that distclean doesn't delete them. Apologies for the bandwidth waste ;) Jules
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote:
>
> Adds the scale method as request by Michael.
> Fixes the EPS detection part, non hacky revision (Garst please test).
Maybe missing an include.
cvs log attached.
Garst
Making all in insets
make[3]: Entering directory `/usr/local/garst/lyx-devel/src/insets'
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../
-I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c
insetgraphics.C
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost -isystem
/usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/insetgraphics.pp -c insetgraphics.C
insetgraphics.C: In function `bool ::isEPS(const std::string&)':
insetgraphics.C:539: `ifstream' undeclared (first use this function)
insetgraphics.C:539: (Each undeclared identifier is reported only once for each
function it appears in.)
insetgraphics.C:539: parse error before `(' token
insetgraphics.C:541: `ifs' undeclared (first use this function)
make[3]: *** [insetgraphics.lo] Error 1
Re: [PATCH] InsetGraphics updates #2
"Garst R. Reese" wrote: > > Baruch Even wrote: > > > > Adds the scale method as request by Michael. > > Fixes the EPS detection part, non hacky revision (Garst please test). > Maybe missing an include. > cvs log attached. > Garst No, it needed using std::ifstream; compiling now. Garst
Re: Rename 666 to TEX
On Sun, Jul 29, 2001 at 02:32:00PM +0200, Asger K. Alstrup Nielsen wrote: > Hi, > > The 666 name is fun, but not very intuitive/informative. What about > changing it to TEX? Failing that, we should at least use ERT, which > is not very intuitive either, but at least more established? > > Greets, > > Asger I totally agree. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: Rename 666 to TEX
"Asger K. Alstrup Nielsen" wrote: > > The 666 name is fun, but not very intuitive/informative. What about > changing it to TEX? Failing that, we should at least use ERT, which > is not very intuitive either, but at least more established? TeX is better, because it's no more like the eval red text. HErbert -- http://www.educat.hu-berlin.de/~voss/lyx/
Re: Rename 666 to TEX
Herbert Voss wrote: > > "Asger K. Alstrup Nielsen" wrote: > > > > The 666 name is fun, but not very intuitive/informative. What about > > changing it to TEX? Failing that, we should at least use ERT, which > > is not very intuitive either, but at least more established? > > TeX is better, because it's no more like the eval red text. It goes away anyway. I like the 666, maybe the same people trying to ban Harry Potter will give lyx some publicity also :) Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: > > > xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. > > Baruch, I suppose you could use ImageMagick identify or something ? > > It might be possible, but then I need ImageMagick for everyone, I'll add > epsi to my list of eps figures. ok, but this won't work for the other cases as I'm sure you know. But maybe asking users to define such converters when they are using admittedly weird file names is not too bad a thing. > If you will commit the patch I've sent last night you won't be bothered maybe you should start talking to someone with global commit privileges :)) regards john -- "I'd rather be rudely informed than politely left in the dark."
Re: graphics problems
On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: > Should I stop auto-converting Old to new for now? or are we better with > this testing? much better ... painful for Garst but hopefully it will become useful enough to stay for the first pre-release ! john -- "I'd rather be rudely informed than politely left in the dark."
Re: GNOME frontend compile problem
On Sun, Jul 29, 2001 at 09:16:22PM +1200, Michael Koziarski wrote: > I just refetched the whole lyx-devel module. Same problem, the only > thing I can think of is a problem with xforms 0.89. Could that be it? afaics your problem seems to be that you have somewhere a forms.h header that is lying about the installed version. nm /path/to/libforms.a | grep fl_set_object_helper ? john -- "I'd rather be rudely informed than politely left in the dark."
Re: graphics problems
John Levon wrote: > > On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: > > > > > xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. > > > Baruch, I suppose you could use ImageMagick identify or something ? > > > > It might be possible, but then I need ImageMagick for everyone, I'll add > > epsi to my list of eps figures. > > ok, but this won't work for the other cases as I'm sure you know. But maybe > asking users to define such converters when they are using admittedly weird > file names is not too bad a thing. Who are you calling weird :) > > > If you will commit the patch I've sent last night you won't be bothered > > maybe you should start talking to someone with global commit privileges :)) Did you commit mpanel.diff? It does seem to cure the problem. Garst
Re: graphics problems
John Levon wrote: > > On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: > > > Should I stop auto-converting Old to new for now? or are we better with > > this testing? > > much better ... painful for Garst but hopefully it will become useful enough > to stay for the first pre-release ! Are you telling me that 1.1.15 and 1.1.16 would not have displayed my weird files? Do you really think that relying on suffixes to determine file type was ever a good idea? What advantage do you see in auto-converting Old to new, and if they are autoconverted, what is the use Old-Graphics? Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 10:42:01AM -0300, Garst R. Reese wrote: > Are you telling me that 1.1.15 and 1.1.16 would not have displayed my > weird files? as a side effect of only supporting eps ... > Do you really think that relying on suffixes to determine file type was > ever a good idea? it's a *reasonable* idea. anyway it should work for you now. it's exactly things like this that needs user testing, so the developer can see what /other/ people do. It's all part of the pain of being a bleeding edge user :) > What advantage do you see in auto-converting Old to new, they're not now if I read current CVS right ... john -- "I'd rather be rudely informed than politely left in the dark."
Re: graphics problems
* John Levon <[EMAIL PROTECTED]> [010729 16:56]: > On Sun, Jul 29, 2001 at 10:42:01AM -0300, Garst R. Reese wrote: > > > What advantage do you see in auto-converting Old to new, > > they're not now if I read current CVS right ... Old Graphics can be created now and was left only as a testing tool (to test auto conversion), I think that my idea of allowing auto conversion override is the best bet for now. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
On Sun, Jul 29, 2001 at 04:43:57PM +0300, Baruch Even wrote: > Garst asked for no auto-conversion and I commented the old InsetFig > back, with permission from Lars I'll introduce a new temporary config > keyword to disable auto-conversion and so it will be possible to disable > it locally in case my code is broken and stops peoples from doing there > work. makes sense I think > Garst does help me check that my fix works for him, though I probably > wouldn't have found about it unless I would have enabled IG for everyone > so brutally. that was exactly my point :) john -- "I'd rather be rudely informed than politely left in the dark."
Re: graphics problems
On Sun, Jul 29, 2001 at 10:30:20AM -0300, Garst R. Reese wrote: > > maybe you should start talking to someone with global commit privileges :)) > Did you commit mpanel.diff? It does seem to cure the problem. I don't even have frontends/xforms right now. We have to wait for Asger, Lars, Angus or whoever to commit regards john -- "I'd rather be rudely informed than politely left in the dark."
Re: graphics problems
* John Levon <[EMAIL PROTECTED]> [010729 16:36]: > On Sun, Jul 29, 2001 at 08:55:21AM +0300, Baruch Even wrote: > > > > > xpm, drd to xpm, plc to xpm, pls to xpm This truly sucks. > > > Baruch, I suppose you could use ImageMagick identify or something ? > > > > It might be possible, but then I need ImageMagick for everyone, I'll add > > epsi to my list of eps figures. > > ok, but this won't work for the other cases as I'm sure you know. But maybe > asking users to define such converters when they are using admittedly weird > file names is not too bad a thing. I'm assuming for now that only EPS is used in such a wierd way, otherwise I'll implement file(1) functionality into LyX for image formats. Right now I'm looking only at a signature for EPS files which is usually at the very start of the file and so is not too much work, and is nothing more than what InsetFig does right now. > > If you will commit the patch I've sent last night you won't be bothered > > maybe you should start talking to someone with global commit privileges :)) I believe in a (local to lyx-*) god who hears all and sees all and has in his eternal wisdom the decision when to give or not to give permissions. Besides, peer-review (assuming it gets done) is not a bad thing. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
* John Levon <[EMAIL PROTECTED]> [010729 16:36]: > On Sun, Jul 29, 2001 at 09:52:47AM +0300, Baruch Even wrote: > > > Should I stop auto-converting Old to new for now? or are we better with > > this testing? > > much better ... painful for Garst but hopefully it will become useful enough > to stay for the first pre-release ! Garst asked for no auto-conversion and I commented the old InsetFig back, with permission from Lars I'll introduce a new temporary config keyword to disable auto-conversion and so it will be possible to disable it locally in case my code is broken and stops peoples from doing there work. Garst does help me check that my fix works for him, though I probably wouldn't have found about it unless I would have enabled IG for everyone so brutally. -- Baruch Even http://baruch.ev-en.org/
Re: graphics problems
John Levon wrote: > > On Sun, Jul 29, 2001 at 10:30:20AM -0300, Garst R. Reese wrote: > > > > maybe you should start talking to someone with global commit privileges :)) > > Did you commit mpanel.diff? It does seem to cure the problem. > > I don't even have frontends/xforms right now. We have to wait for Asger, Lars, Angus > or whoever to commit OK, but the ChangeLog got rejected here. Surprise surpise. Did you request a commit? Garst
Re: graphics problems
On Sun, Jul 29, 2001 at 02:47:50PM +0100, John Levon wrote: > > What advantage do you see in auto-converting Old to new, > > they're not now if I read current CVS right ... Yup. UserGuide.lyx displays again. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc. | Laura Isabella Sylvan | Katherine Yelena (8/8/89) http://sylvan.com/~kayvan | "crown of her husband" | Robin Gregory (2/28/92)
Re: [PATCH] InsetGraphics updates #2
Baruch Even wrote: > > Adds the scale method as request by Michael. > Fixes the EPS detection part, non hacky revision (Garst please test). > > The scale option is added to the horizontal part but affects both > horizontal and vertical, bad UI, I know. Consider this a proof of > concept, and if someone won't do the UI fix I'll do it some other time. > > -- > Baruch Even > http://baruch.ev-en.org/ > > > Name: ig2.diff.gz >ig2.diff.gzType: unspecified type (application/octet-stream) > Encoding: base64 Looks good here. Got all of "weird" filenames with no sweat. mathpanel patch also retested. Thanks much, Garst
Re: [PATCH] InsetGraphics updates #2
On Sun, Jul 29, 2001 at 02:42:48PM +0300, Baruch Even wrote: > Adds the scale method as request by Michael. > Fixes the EPS detection part, non hacky revision (Garst please test). > > The scale option is added to the horizontal part but affects both > horizontal and vertical, bad UI, I know. Consider this a proof of > concept, and if someone won't do the UI fix I'll do it some other time. Looking at the patch, it seems that if you have foo.epsi, lyx will try to convert it to foo.eps ... Also, why did you define epsi format in your previous patch ? One argument in Converter::Convert is the format of the from_file, so it can be used as follows: converters.Convert(..,"foo.epsi",..., "eps", "pdf")
Re: graphics problems
On Sun, Jul 29, 2001 at 08:59:17AM +0300, Baruch Even wrote: > * Kayvan A. Sylvan <[EMAIL PROTECTED]> [010729 08:56]: > > On Sun, Jul 29, 2001 at 02:20:13AM -0300, Garst R. Reese wrote: > > > > > > > > What do I need to do to get this to work? > > > > > > > netpbm has pstopnm and ppmtoxpm, but pstopnm just runs ghostscript. Why > > > go to xpm at all? > > > > Baruch, > > > > Can you provide the script/whatever is necessary to make the new Graphics > > inset work? We should also consider adding it to the lyx sources, somehow. > > I can easily provide the toxpm magic to convert, but this will be a > temporary bandaid until I create my specialy customized ImageTransformer > to do resize/dither/cropt/rotate of images on screen. Note that convert can do all these transformation. Also, if you are planing to use convert (which give you no library dependency), then use it with pipes, e.g. convert file.gif xpm:-
unimportant license issue
shouldn't we word the GPL exception as suggested here : http://www.gnu.org/licenses/gpl-faq.html#TOCWritingFSWithNFLibs ? thanks john -- "I'd rather be rudely informed than politely left in the dark."
