idraw 1.2.6 files sometimes make ghostscript fail possibly due to a buggy non-visible element

Hi,

I noticed that sometimes files created by idraw 1.2.6 cannot be processed
by ghostscript, which fails with an error (lines are formatted)

------------------------------------ 8< ---------------------------------
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--
   % --nostringval--   2   %stopped_push   --nostringval--   --nostringval--
   % -- --nostringval--   false   1   %stopped_push   1862   1   3
   % -- -- %oparray_pop   1861   1   3   %oparray_pop   --nostringval--
   % -- -- % 1845   1   3   %oparray_pop   1739   1   3   %oparray_pop
   % -- -- % --nostringval--   %errorexec_pop   .runexec2   --nostringval--
   % -- -- % -- --nostringval--   --nostringval--   2   %stopped_push
   % -- -- % -- -- --nostringval--   --nostringval--
Dictionary stack:
   --dict:1154/1684(ro)(G)--   --dict:0/20(G)--   --dict:81/200(L)--
   -- --dict:33/50(L)--   --dict:1/17(L)--   --dict:14/17(L)--
Current allocation mode is local
Current file position is 8551
GPL Ghostscript 8.70: Unrecoverable error, exit code 1
------------------------------------ 8< ---------------------------------

I could not yet isolate what is exactly triggering the problem during
edition, but noticed that in a buggy file, when I remove visible elements
in a one by one basis (individual select+delete), I end up with a
supposedly empty file that is still buggy.

If I then do a 'select all', nothing is shown as selected, but if issue the
delete command from the menu or the 'x' key file is marked as changed, and

ivtools build failures with gcc40 in 64 bit arches

Hi,

The old build failure due to the different pointer lenght in 32 and 64 bit
arches came back,

http://bugs.debian.org/545834

The reason is that not all issues from http://bugs.debian.org/314666 were
fixed with the applied patch. Note that a pointer does not fit in an integer
on 64 bit arches. A pointer is 64 bit, an integer 32 bit.

I am attaching a quick and dirty patch which mostly does what was proposed
in #314666 for that part, but using c99 typedefs intptr_t and uintptr_t,
from libc6 stdint.h, instead of unconditional long. I think they are present
in current libc variants, but you may prefer something more general or
moving its use for boolean to the boolean definition.

Hope this helps anyway.

Cheers,

--

-- 
Agustin

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 

InterViews updates

Hello,
in the last several weeks I have been tinkering with the InterViews and
Unidraw parts of ivtools.  My main motivation is to get reaccustomed with GUI
programming, and InterViews' clean design is very helpful for this.

While I'm aware that ivtools is in deep maintenance mode, some of my
modifications may still be of interest to you: 
	- Improved UTF-16 and UTF-8 support
	- Use of 'bool' and min/max from libc++
	- Replaced the macros for generic types like List, Table, Action
	  and some special callbacks with templates.
	- Reimplemented List and Table with std::deque and std::map
	- Extended Actions with up to 3 arguments
	- Introduced smart pointers for automated Resource management
	- Switched IV-3.1, IV-Look and IV-X11 from manual Resource
	  management to smart pointers
	- Replaced the Unidraw low-level containers (UArray, UList, UMap,
	  UHashTable) with templates.
	- Switched the internals of some Unidraw classes to smart pointers
	  and containers from the C++ standard library.

The current changes are against a modified version of the Debian package
and some make use of rather new features of C++.  But if there is enough
interest for some of the listed items I'm willing to recreate the patches
against current, pristine ivtools sources and test with older compilers.

Have a nice Day
  Gert-jan
PS: My first email used a different From adress and seems to be stuck in moderation

Build errors

Hello.  Parts of ivtools fail to build with gcc 4.0.

There is a patch for version 1.1.3 at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=314666

Apparently at least some of the modifications in there apply for 1.2.2
too. I haven't yet gone through 1.2.2 myself, but you might want to
look at the patch anyway.

-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP, 
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar

How about porting to C++ iostreams?

Hi friends,

recently i've looked at the newest ivtools.
Well, i think the method of wrapping all around the
old headers is quite ugly.

How about doing a straigt replacement of the
old InterViews with the new headers?

Currently i'm doing this work on my old IV3.1-nls
with some fixes inside, to use it with gcc-3.4.3.
I'm using IV since one of it's first versions
in '92 ... (this should tell all 

BTW, does anybody know where and why ibuild
did disappear from ivtools?

regards, Eduard

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Sequence of InterViews 3.1 canvas.curve_to to Idraw BSpl

I see in ivtools-1.2/src/IVGlyph/figure.c
how to convert *_BSpline31 arrays into a sequence of curve_to calls.
But I need to go the other way.
My application uses curve_to and contains an Idraw file writer which
needs to convert them to a BSpl or CBSpl.
Does anyone know the algorithm?

By the way, if anyone is interested, I've long been maintaining
a mac os x carbon and MSWindows version of InterViews 3.2a for use
with my application and the tar.gz file can be found at
http://www.neuron.yale.edu/neuron/install/install.html
It builds using an autoconf generated configure file. With X11
it also builds the original idraw using
the Unidraw and InterViews-2.6 compatibility classes, but I never
got around to porting the InterViews-2.6/x*.c files to carbon or
mswin so idraw never made it to those places.

-Michael Hines

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

Any information on HPs InterViews Plus?

I am currently attempting to port some software that used HPs IVPlus implementation of InterViews.

The source tree that I have is incomplete.

If anyone has any information on IVPlus or how I can optain a complete distribution, please contact me  <at> 
batkinson <at> cfl.rr.com or post to the distribution list.

Thanks.

Brian Atkinson
Orlando, FL

-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

test e-mail

This is an e-mail to test the ivtools-devel mailing list.  I approved a 
post from mike at palczewski dot net earlier today.  The subject was 
some newly generated RPM's.  But the e-mail never came through, and I 
don't have a copy of it.  Mike, if you read this, please forward 
another copy, and cc me.

Scott Johnston

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

rpms

Hi, I just build rpms for the latest ivtools source packages.  They have 
been tested on redhat 9 and 8. 

You can find them here. 
http://evolution.gs.washington.edu/~mpalczew/

Is there an official place to upload them? or is there someone in charge 
of this?

-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver
higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3

rpm package for ivtools.

I prepared a rpm package for ivtools-1.0.7.
The source package is in http://leon.bottou.com/files/ivtools-1.0.7-1.src.rpm.
The spec file and the patch files are attached.
- the first patch (ivtools-rpm.patch) makes various makefile changes 
  that redefine the set of files to install.  This comes from a old ivtools package
  and I did not try to think to hard.
- the second patch (ivtools-bug.patch) removes a default argument in
  a function definition.  This causes a compile error with gcc-3.2.

- Leon Bottou

Summary: A collection of vector-graphic drawing editors
Name: ivtools
Version: 1.0.7
Release: 1
Copyright: MIT
Group: Applications/Multimedia
Source: http://prdownloads.sf.net/ivtools/ivtools-1.0.7.tgz
Patch: ivtools-rpm.patch
Patch1: ivtools-bug.patch
BuildRoot: %{_tmppath}/%{name}-root

%description
ivtools is a collection of vector-graphic editors derived
from idraw.

%prep
%setup -q -n ivtools-1.0

Re: Can we use Interviews on Red Hat Linux 7.3 ?

At 3:43 PM +0800 1/10/03, tongjl <at> ses.st.com.sg wrote:
>Hi Scott,
>
>Thanks for your reply. In fact, i am interested in the porting of
>Interviews from Unix to Red Hat Linux only. Do you know how complex it is
>to port Interviews from Unix to Linux? Or is there anyone else i can
>consult? Thanks again Scott. Your reply is very much appreciated.
>
>Regards,
>David
>

Porting InterViews to RedHat 7.3 is more about changing InterViews to 
get it compiled with a recent version of gcc.  As far as I know, no 
one has been getting InterViews compiled with recent versions of gcc. 
Several years ago there used to be an RPM for iv-3.1, but I haven't 
seen it in the last few years. And there have been a lot of (minor) 
changes over the years required to these libraries, I know, because I 
went through them all.  Most of it is conformance to the ANSI 
standard.

You can use the ivtools source tree as a reference, but I really 
think it would be less work for you to use the InterViews and Unidraw 
libraries out of the ivtools source tree.  They are the same for the 
most part, with only bug fixes and compilation fixes accrued over 
time.

Scott Johnston
http://www.ivtools.org