ivtools-devel

Re: Arrows in UniIdraw

[Scott J. <sc...@ac...>]

David Nowak wrote:

>Hello,
>
>I started to develop my own graphic editor with Unidraw. My small program
>compiled and ran well. But I needed arrows. Unfortunately Unidraw cannot deal
>with arrow, can it? Thus I used UniIdraw in order to have arrows: I added a few
>#include:
>
>  #include <UniIdraw/idarrows.h>
>  #include <UniIdraw/idarrow.h>
>
>and the lines
>
>  ArrowLine *
>    line = new ArrowLine (0, 0, unit, unit, false, false, 1., stdgraphic);
>  ArrowLineComp *
>    arrowLineComp = new ArrowLineComp (line);
>  Include (new
>	   GraphicCompTool (new
>			    ControlInfo (arrowLineComp, KLBL_LINE, CODE_LINE),
>			    arrowLineComp), tools);
>
>in my source code.
>
>Now, it compiles well but it terminates on a segmentation fault when it calls
>the constructor for GraphicCompTool!
>
>I compile, with Gun C++ 2.95.2 in Linux RedHat 6.2, this way:
>
>c++ -Div2_6_compatible -g -c -I $PREFIX/include/IV-2_6 \
>    -I $PREFIX/include diaged.c
> 
>c++ -Div2_6_compatible -g -c -I $PREFIX/include/IV-2_6 \
>    -I $PREFIX/include main.c 
>c++ -Div2_6_compatible -g -o diagram -L $PREFIX/lib -lUniIdraw \
>    -lUnidraw -lIV -L /usr/X11R6/lib -lXext diaged.o main.o
>
>Can anyone help me?
>
>Manny thanks,
>
>David.
>  
>
David,

Maybe gdb can help you.  Run it via emacs (M-x gdb) and it will show you 
exactly
where the segmentation fault occurs, and you can probe the value of any
variable to see what is wrong.

Or maybe you have object code that is out of synch with the source code. 
 If you
are running it in gdb, and the segfault occurs right when you step into 
the constructor
and there is no other evidence of anything going wrong, this is probably 
the problem.

Deleting all the .o's and rebuilding them is one way of dealing with 
this.  In the ivtools source
tree you can do a "make depend" to refresh the dependencies (stored in 
Makefile.depend)
and a subsequent "make" will rebuild all object code where a change has 
occurred
either directly to the module or indirectly in a .h file.

Jut out of curiousity, what kind of drawing editor are you building?

Scott Johnston
http://www.ivtools.org

Arrows in UniIdraw

[<now...@ya...>]

Hello,

I started to develop my own graphic editor with Unidraw. My small program
compiled and ran well. But I needed arrows. Unfortunately Unidraw cannot deal
with arrow, can it? Thus I used UniIdraw in order to have arrows: I added a few
#include:

  #include <UniIdraw/idarrows.h>
  #include <UniIdraw/idarrow.h>

and the lines

  ArrowLine *
    line = new ArrowLine (0, 0, unit, unit, false, false, 1., stdgraphic);
  ArrowLineComp *
    arrowLineComp = new ArrowLineComp (line);
  Include (new
	   GraphicCompTool (new
			    ControlInfo (arrowLineComp, KLBL_LINE, CODE_LINE),
			    arrowLineComp), tools);

in my source code.

Now, it compiles well but it terminates on a segmentation fault when it calls
the constructor for GraphicCompTool!

I compile, with Gun C++ 2.95.2 in Linux RedHat 6.2, this way:

c++ -Div2_6_compatible -g -c -I $PREFIX/include/IV-2_6 \
    -I $PREFIX/include diaged.c
 
c++ -Div2_6_compatible -g -c -I $PREFIX/include/IV-2_6 \
    -I $PREFIX/include main.c 
c++ -Div2_6_compatible -g -o diagram -L $PREFIX/lib -lUniIdraw \
    -lUnidraw -lIV -L /usr/X11R6/lib -lXext diaged.o main.o

Can anyone help me?

Manny thanks,

David.

___________________________________________________________
Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com

leading up to ivtools-1.1

[Scott J. <sc...@ac...>]

In pushing towards ivtools-1.1 (due in the fall, as usual), I'm looking at
wrapping up a full-featured implementation of the alpha-transparent,
anti-aliasing mechanisms people have come to expect in their
drawing editors.  You really don't need the anti-aliasing until the
drawing gets rendered via ghostscript, but  you want it, don't you.

My plans have been informally documented here:

    http://advogato.org/person/sej/diary.html?start=139

But these are the goals:

    - alpha-transparent rasters with EPS export/import
    - user-selectable global anti-aliasing mechanism by
        rendering to pixmap at 2x, and reducing on the fly
    - polygon-clipped rasters with EPS export/import

This postpones things like PorterDuff alpha-compositing
(with an 8-bit key or mask) and Sketch-like blend-groups
(however you do those), but it augments the easy-to-use,
easy-to-understand GUI of idraw with modern-day tools.

Scott Johnston
 http://www.ivtools.org

test build of 1.0.3 on HPUX

[Scott J. <sc...@ac...>]

Is anyone in a position to do a test build of ivtools-1.0.3 on
HPUX?  Things should be building smoother nowadays,
but I'd like to confirm that and remove any last wrinkles.

Scott Johnston
http://www.ivtools.org

state of ivtools

[Scott J. <sc...@ac...>]

Greetings to everyone on the ivtools-devel mailing list,

Development of ivtools has been slow (yet steady) for the past year
and a half since I took a full-time job as a software engineer in the
video broadcast industry.  Now with the advent of 1.0 there is some
indication this might change, as a wider audience of users and potential

developers give ivtools a try.

ivtools now compiles with both gcc-2.95.* and gcc-3.0.*, links against
both libstdc++-v2 and libstdc++-v2, and works on a variety of
platforms:  every Linux, FreeBSD, NetBSD, a host of older Unix'es,
Cygwin on Windows, and most likely Mac OS X in the near future.

As always, the basic capability of idraw has been preserved, and from
time to time ancient bugs are fixed, or extensions are made to the idraw

format.

On top of idraw is the layering of frameworks that augment idraw with
additional mechanism of potential interest to application developers.
The layering is such that you can grab just the amount of layers you
need for vertical application, and start building on top of that subset
without having to master the whole stack.  And in the future you can
still slip other layers underneath your application as needed.

But frankly, I'm not aware of anyone making use of ivtools in this
manner at present.  Although it is a unique result of interest to
computer scientists, most end-user applications written in the
world of free software are monolithic point applications.

So why not make our own stand-alone applications, tuned to appeal
to a given audience?  Of course, this being ivtools, I would like to
suggest more than one.

The first focus is a simple, youth-friendly vector-graphics editor
that builds on the easy-to-use interface of idraw (as opposed to
the competition which starts with the goal of cloning Illustrator).
What if Apple was shipping a vector-graphic drawing editor with
MacOS X to complement iTunes, iMovie, etc.? That's right, think
iDraw!  In ivtools, iDraw (with a capital D) would be an evolution
of drawtool, either in-place or on-top.  It would remain a simple
editor, perhaps even simpler than it is today, yet full-featured in
a way that would please a parent who makes their living using
professional graphical editing tools.

The second focus is complex and leading-edge, the evolution
of drawserv to live up to its name, whatever that entails.  Imagine
a server for group creation,  transformation,  and publishing of
vector-graphics.  Imagine sketching out a storyboard with
other artists working in parallel, with all the support necessary
for committing and reversing changes to the master copy, with
the freedom to branch your effort at anytime.  Imagine hierarchical
structured graphics composed of hyperlinked fragments with
arbitrary transformations to coordinates and graphic state.
Imagine putting such a tool in the hands of college students
bored with textual hyperlinks and web-based chat-rooms.

There are a variety of  tasks ahead of us before either promise
is even partially fulfilled.  Yet no other software package is
as well positioned to do both, with an iceberge of capability
lurking beneath the current user interface on the surface.  Ask
questions here to increase your understanding of what to do,
and how to do it.  Volunteer for what you can, get others
to volunteer for the rest.

Scott Johnston
http://www.ivtools.org

p.s. by the way, you can choose to digest this mailing list if traffic
gets too high for you:

http://lists.sourceforge.net/lists/listinfo/ivtools-devel

[Fwd: ivtools for Debian Jr.]

[Scott J. <sc...@ac...>]

Re: Changes to ivtools-drawtool

[Scott J. <sc...@ac...>]

Glen Koundry wrote:

> > Two comments about work so far:  1) feel free to do generic work
> > like this in place, in the existing methods and classes (I do understand
> this was
> > just an initial experiment);
>
> The reason I put the code in a new file was that I thought that the
> OverlayUnidraw API was a completely separate project, like Unidraw.  Are
> there any guidelines as to what source can be modified and what can't?
>

Anything can be modified, given a good reason.  We try to preserve idraw as is,

which means leaving the UniIdraw and Unidraw class libraries alone for the
most part. But the classes of OverlayUnidraw are the place to evolve generic
extensions.  The only question is whether it is an evolution to an existing
class
which should happen in place, or the creation of new classes which should be
done in new files.

>
> > 2) I like the double row of toolbar buttons, but it
> > certainly begs for some mechanism to preserve a natural height to the
> entire toolbar
> > panel(to preserve the natural shape of the drawing editor, whatever that
> would be).
>
> I am not sure what you mean by "natural height".  I have been working on
> trying to make the program choose the appropriate number of columns for the
> toolbar based on the window size (ie. as the window's height increases,
> fewer columns are needed for the tool buttons).  If you have any hints on
> how to detect changes in window size that would help.  I've tried using the
> Observer/Observable interface via:
> GetEditor()->GetOverlayViewer()->GetOverlayView()->GetOverlayComp()->attach(
> new MyObserver), but it doesn't seem to detect size changes, just drawing
> events

I believe you can do what you want within the Glyph API, as documented in the
InterViews 3.1 Reference Manual:

http://www.ivtools.org/ivtools/doc/refman3.1/refman.html#PAGE13

My rough understanding is a Glyph asks for a certain amount of space
to draw in with a Requisition, is given a certain amount of space to draw
in with an Allocation and declares how much it will actually use by
returning an Extension.  After a window resize I
believe every glyph will receive a new Allocation passed to the
::allocate method, for which it has to compute a new Extension.

The idea would be to specialize the ::allocate method of one
of the glyphs constructed in OverlayKit::MakeToolbar to
dynamically rearrange the glyph sub-tree as needed.

Scott Johnston
http://www.ivtools.org

RE: Changes to ivtools-drawtool

[Glen K. <gl...@mi...>]

> Two comments about work so far:  1) feel free to do generic work
> like this in place, in the existing methods and classes (I do understand
this was
> just an initial experiment);

The reason I put the code in a new file was that I thought that the
OverlayUnidraw API was a completely separate project, like Unidraw.  Are
there any guidelines as to what source can be modified and what can't?

> 2) I like the double row of toolbar buttons, but it
> certainly begs for some mechanism to preserve a natural height to the
entire toolbar
> panel(to preserve the natural shape of the drawing editor, whatever that
would be).

I am not sure what you mean by "natural height".  I have been working on
trying to make the program choose the appropriate number of columns for the
toolbar based on the window size (ie. as the window's height increases,
fewer columns are needed for the tool buttons).  If you have any hints on
how to detect changes in window size that would help.  I've tried using the
Observer/Observable interface via:
GetEditor()->GetOverlayViewer()->GetOverlayView()->GetOverlayComp()->attach(
new MyObserver), but it doesn't seem to detect size changes, just drawing
events.


> As for submitting work, you have two choices: via cvs with developer
permissions
> (which I will give you shortly), or via informal patches e-mailed to
> ivt...@li....  If you choose to use patch I will
keep
> the cvs repository in synch myself.  If you use cvs it would be helpful if
you sent
> an e-mail to ivt...@li... after committing a set of
changes
> that will go into a formal patch.  There is an automatic notification of
commits
>but a redundant notice will help me keep things organized (and inform
others
> of progress).

OK, I will submit my preliminary changes to CVS some time today.

Re: Changes to ivtools-drawtool

[Scott J. <sc...@ac...>]

Glen Koundry wrote:

> Scott,
>         I've been going through the documentation for the various API's and have
> even done a small amount of work on the drawtool program (I changed the
> toolbar to have two rows of buttons).  I just had a few questions, namely:
> a. How do you handle code changes?  Is there some sort of CVS setup? and b.
> Are there any sort of coding standards (ie. file names, source code
> comments, etc.) that I should be aware of?  I have attached the changes I
> made and would appreciate it if you could look it over when you get a
> chance.
>
> Thanks
>
>   ------------------------------------------------------------------------
>                    Name: drawtool.zip
>    drawtool.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>                Encoding: base64

Glen,

Once again I'm forwarding this to ivt...@li..., because
I want to be able to point people's browsers to the following reference material
in the future.

Work to date:

I tested your new stuff in my development source tree by replacing the body of
OverlayKit::MakeToolbar with what you created in
CustomOverlayKit::MakeToolbar.  Works fine, looks great.
But I will back out this change for now, and let you submit through normal
channels (to be discussed below).

Two comments about work so far:  1) feel free to do generic work
like this in place, in the existing methods and classes (I do understand this was
just
an initial experiment); and 2) I like the double row of toolbar buttons, but it
certainly
begs for some mechanism to preserve a natural height to the entire toolbar panel
(to preserve the natural shape of the drawing editor, whatever that would be).


Submitting work:

As for submitting work, you have two choices: via cvs with developer permissions
(which I will give you shortly), or via informal patches e-mailed to
ivt...@li....  If you choose to use patch I will keep
the cvs repository in synch myself.  If you use cvs it would be helpful if you sent

an e-mail to ivt...@li... after committing a set of changes
that will go into a formal patch.  There is an automatic notification of commits
but a redundant notice will help me keep things organized (and inform others
of progress).

In either case I will take it upon myself to incorporate your changes into the
source tree I use for generating release tarfiles, and archive the change by
authoring a formal patch which gets posted at
ivt...@li....  Visit here to see formal patches to-date:

http://sourceforge.net/mailarchive/forum.php?forum_id=5713


Standards and conventions:

C++ filenames are all lower-case, with a .c  instead of .cc or .cxx for
historical reasons.  Typically there is one class per file, and the filename
is lower-case version of the classname, simplified if necessary to keep
a reasonable length (8 to 12 characters?).  For example, OverlayKit can
be found in ovkit.c.

Sometimes filenames contain a prefix that relates them to the class
library they are part of.  This is mostly used for derived classes that
are central to the drawing editor framework (like oved.c which contains
OverlayEditor).  But new mechanisms break this rule (slctbyattr.c
contains a SelectByAttributesCmd), and it was kind of redundant
since you always refer to include files using the both the class
library and the file name, i.e.:

    #include <OverlayUnidraw/ovkit.h>

Each fragment of a classname is capitalized (unlike Smalltalk, etc..,
which capitalize all but the first fragment).  Macros are all CAPS (except where
they're not trying to look like a macro).  Variables are all lowercase.
Member variables have a trailing or leading underbar.  Older methods related to
the IV-2_6 layer and Unidraw are capitalized.  Younger methods related to
the IV-3_1 glyphs and ComTerp are lower case.

Of course there's more, but a lot of it you can learn in a monkey-see, monkey-do
fashion, or I'll offer feedback as we go.  The primary convention is the code works

and does something useful an interesting.  Everything else is secondary :-)

Any questions?

Scott Johnston
http://www.ivtools.org

RE: Swing developer interested in C++

[Scott J. <joh...@ve...>]

>hi,
>
>i would like to contribute.

Here is an e-mail I sent earlier this week to another interested 
party (apologies for its impersonal nature, but it saves me a lot of 
typing):

http://sourceforge.net/mailarchive/forum.php?thread_id=466722&forum_id=5715

All this applies equally well to you.  Welcome, and hope to hear more 
from you soon.

Scott Johnston
http://www.ivtools.org

RE: Swing developer interested in C++

[Scott J. <joh...@ve...>]

>Can u get me some more detail information on this.
>Presently I learned all these things c,c++,java
>(awt,swing,etc)
>Hope I be useful in ur project.
>Expecting an acknoledgement
>Thanx
>praveen


praveen,

Here is an e-mail I sent to another interested party.  This information
applies equally well to you:

http://sourceforge.net/mailarchive/forum.php?thread_id=466722&forum_id=5715

The only thing I might add is that we also have need for better 
color-selection dialog boxes and/or drawing editor add-ons.

Welcome, and hope you find the project interesting.

Scott Johnston
http://www.ivtools.org

RE: Swing developer interested in C++

[Scott J. <sc...@ac...>]

>
>Hi,
>     I have plenty of experience creating Swing interfaces
>and know C++ pretty well too.  If the position is still
>open, I'd like to help.

Glen,

Welcome.  There is still work available.  drawtool might be the
place to start:
      http://www.ivtools.org/ivtools/drawtool.html

To familiarize yourself with the user-interface widgets of ivtools
start reading here:
      http://www.ivtools.org/ivtools/glyphinfo.html

 The first thing we could use help with is converting the toolbar
(or tool-pallette) to be 2 or more columns of graphical buttons.
Right now it is a single column of mostly text buttons.  It would also
be nice if we had the ability to dynamically reposition to the left or
right of the canvas.  This is already supported as a command line
option, but doesn't work on the fly.

The second thing would be adding a row of graphical button
shortcuts for pull-down menu items (i.e. "New", "Save", "Print", etc..)
Since this command-bar is redundant with the pull-down menus
it should be optional, removable (or retrievable) with a click.

After that things might suggest themselves to you.  We can keep an
organized list of hoped-for feature extensions at the Sourceforge
project page.

Review the above material (and related links), and if you're still
interested, subscribe to the ivtools-devel mailing list, sign up as
a developer at SourceForge, and start programming.

Scott Johnston
http://www.ivtools.org

p.s. feel free to ask me anything.  I cc info-laden
responses (like this one) to the ivtools-devel mailing list to
keep an archive useful for others.

p.p.s.  what's your development machine?

Re: IVtools progress...

[Scott J. <sc...@ac...>]

> Have you done anything on IVtools lately? Get anything done over
> the holiday break? Whats the word on Ivtools-1.0.1?
>
>

Over break I focused on OS X.  Then I'm going to network a Linux box to it.

Ivtools-1.0.1?  Well, it will have your new Time.[ch].  And...

- "None" background color (for semi-transparent patterns)
- comdraw raster commands for creation, pixel poking, and polygonal clipping
- handful of bug fixes

I plan on cranking it out in the next week or so.  Got anything to add?

Scott

ivtools-0.9.7 is beta-test for 1.0

[Scott J. <sc...@ac...>]

ivtools-0.9.7 is out.  You can consider it a beta-test for ivtools-1.0.
As soon as I can verify successful builds on a quorum of operating
systems, I will roll the version number to 1.0 and redistribute.  Please
grab a copy and do a test build with your latest variant of Unix and
gcc, and report results to ivt...@li....  I will
keep track of them on this web page:

http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=39239&group_id=275&group_project_id=13654

New features in 0.9.7:

APL-like auto-vectorization of scalar operators in the embedded command
interpreter.  A stream times a scalar yields a stream.  For more
details:

http://www.ivtools.org/ivtools/ivtools-0.9-CHANGES.txt

Scott Johnston
http://www.ivtools.org

p.s. any suggestions or comments on how to best manage the 1.0 roll-out
would be appreciated.  Please e-mail to
ivt...@li... as well.

more ACE/iostream good-news/bad-news

[Scott J. <sc...@ac...>]

The good news is I figured out what was problematic in building and
using ACE from ivtools for the past few years.  The secret is to disable
threads support.  The INSTALL file in the repository (or modified with
the latest patch from the patch mailing list) describes what to do.

The bad news is the iostreams of libstdc++ v3 are not very socket
happy.  There is a filebuf constructor which takes a FILE* argument
which can be generated from a socket descriptor using fdopen, but the
resultant istream doesn't work.  Same for ostream's.  Earlier today
I added a derived filebuf and derived ostream that (to
src/include/ivstd/iostream.h) that accept a socket descriptor, and it
works as long as you avoid ostream::put, which for some reason disables
subsequent output.

So now that I know the territory, I'm taking a break from all this, and
waiting to see if a filebuf::attach method will get re-instated in
libstdc++ v3.  The problem started when Microsoft chose to treat socket
descriptors as distinct from file descriptors, so for the
ANSI C++ iostreams to be "portable" they had to restrict constructors to
using pathnames.  If I could figure out how to use a pathname to get at
a socket I'd be all set.

Scott

more gcc-3.0 / libstdc++v3 improvements

[Scott J. <sc...@ac...>]

Attached is a patch that adds several important improvements to
ivtools-0.9.4 when compiling with gcc-3.0 (over and above the changes
incorporated in that release).  It reduces optimization from -O6 to -O2,
which ensures the compilation will complete in a reasonable amount of
time.  It fixes the export/import mechanism's use of libstdc++ v3
iostreams.  And it makes the necessary changes for building with ACE.

These changes are also incorporated in the cvs repository at
http://sourceforge.net/projects/ivtools

It looks like the worst is over in migrating to gcc-3.0, and I'm really
relieved.

Scott Johnston
http://www.ivtools.org

Re: Interviews Queries

[Scott J. <joh...@ve...>]

At 9:36 AM +0800 6/1/01, to...@se... wrote:
>hi Scott,
>
>       Thanks for replying. I really appreciate it.  I'm aware of the
>PullRightMenu method, but because my list is too long, i cannot use
>PullRightMenu to do it.  So i'm wondering if there is such a way to do it
>as i mentioned below...
>
>Regards,
>David
>


I see.  Your list is long *and* flat.  Maybe it would be a better 
idea to have a single menu item that brought up a stringchooser 
dialog box?  From there you could scroll through an arbitrarily long 
list of items, and perform the same action when you Accept as you 
would have directly from the menu?

As for doing what you described, I haven't seen anything like this, 
but that doesn't mean it isn't possible. You want to dynamically 
change the contents of a menu while the menu is still open.  With 
InterViews it would be possible, by traversing the list of MenuItem's 
and removing them as you, then inserting all the new MenuItem's, then 
a repair.  I'm sorry, I don't have the exact API references handy, 
but the InterViews glyphs can be treated like a tree of structured 
graphics, and inserts and deletes done on the fly, and a repair 
invoked at the right place you will see what you want on the screen. 
Good luck.

Scott Johnston

Re: suggestions on building ivtools

[Scott J. <joh...@ve...>]

I would recommend that you search in IVGlyph/SUN4 for the undefined 
reference to LLC24 (by using nm on every .o), then when you find it, 
recompile that module with a -E argument which will generate the 
pre-processor output.  Then study this to get an idea of what include 
file created the LLC24 reference, and what to do about.  Forward that 
-E output to ivt...@li... if you need help in 
deciphering it.

Scott Johnston
http://www.ivtools.org

Re: Interviews Queries

[Scott J. <joh...@ve...>]

>hi,
>
>    I am a Software Engineer working on Unix platform using Interviews.
>I've met with this problem and wonder if you can direct me to the best
>person who can help me.  I was working on a Menu Bar and because the list
>gets too long, i've included a MenuItem in the Menu List called 'Next" so
>the when the use clicks on 'Next', it will go to the next Menu List.
>However, when i clicked on 'Next', the menu list closes and i have to
>manually click on the Menu again in order to view the next list under the
>same Menu.. Is there a way/predefined function that allows me to keep this
>menu list open? or is there a way to automatically depress the Menu so that
>a new list would come out when the old list closes?
>
>Thanks.
>
>Regards
>David

I would recommend the use of nested menus.  I don't recall how to do 
this off of the top of my head, so I'm forwarding this to the devel 
mailing list where you might get some answers.  It involves using a 
PullRightMenu for the MenuItem, or something like that.

Scott Johnston
http://www.ivtools.org

patch: output: backslashes

[John D. <js...@re...>]

Here is a patch that will allow ivtools to correctly output text objects 
that contain backslashes.

*** paramlist.c.orig    Mon Mar 19 15:29:18 2001
--- paramlist.c Fri May 25 20:10:19 2001
***************
*** 946,961 ****
             dot += text.Insert(dot, buf, sizeof(buf) - 1);

         } else {
!           switch (c) {
!           case '\\':
!               dot += text.Insert(dot, "\\", 1);
!               // fall through
!           case '"':
!               dot += text.Insert(dot, "\\", 1);
!               // fall through
!           default:
!               dot += text.Insert(dot, string, 1);
             }
         }
       }
       text.Insert(dot, "", 1);
--- 946,955 ----
             dot += text.Insert(dot, buf, sizeof(buf) - 1);

         } else {
!           if (c == '\\' || c == '"') {
!             dot += text.Insert(dot, "\\", 1);
             }
+           dot += text.Insert(dot, string, 1);
         }
       }
       text.Insert(dot, "", 1);

Re: color bitmaps saved in idraw format aren't right postscript

[John D. <js...@re...>]

I wrote:

>>In an effort to find a workaround for the problems in the previous 
>>paragraphs, I created a new drawing, bar.ps.  I tried to import the valid 
>>color postscript (foo.ps2).  That did not work. This is a bug.

Then at 01:00 AM 4/7/01 -0700, Scott Johnston wrote:

>Can you forward a copy of foo.ps2?

Help yourself to
   http://www.monmouth.com/~jsd/foo.ps2
which is the version created with the P (print) command.  Alas it cannot be 
imported back into drawtool.

Contrast this with
   http://www.monmouth.com/~jsd/foo.ps
which is the version created with the ^X (export) command.  It can be 
imported into drawtool.  Alas it doesn't look right when sent to an 
ordinary postscript interpreter such as ghostscript.


>>It did however print an error message on the terminal, namely
>>         "unknown graphical object ColorRast"
>
>
>Ok, it sounds in this case pstoedit is not getting invoked for some 
>reason, either the file is falsely detected as idraw format, or you don't 
>have pstoedit in your search path.

1) It depends on what you mean by "falsely".  With one obvious exception, 
when I prepare a file using the P (print) command, I can import the file 
into idraw and drawtool just fine, and it is correctly (not falsely) 
recognized as idraw format.  The imported object has all the structuring 
information.

The exception is that print-files containing color bitmaps cannot be 
imported at all.

Obviously it would be preferable for all such files be *correctly* detected 
as idraw format.

2) It is true that I don't have pstoedit in my $PATH, or anywhere else.  I 
don't see why it should be needed for what I want to do.
  -- Drawtool and idraw can import bitmaps from foo.ps just fine;
  -- Why can't they import bitmaps from foo.ps2?  There's not any obscure
     or tricky decoding involved.

3) If the lack of pstoedit is relevant, the import command should detect 
this and print a more-informative error message.

4) Note that color is only part of the story in the print-files.  Importing 
grayscale bitmaps fails, rather like the color case.  The error message in 
this case is
         unknown graphical object GrayRast
However the problem is less significant in this case, because the 
export-file has a usable representation of the grayscale image and (unlike 
the print-file) is importable.

>Perhaps when you see flatten things you mean everything is grouped into 
>object?  Try the Structure/Ungroup command a few times when that one thing 
>is selected, to see if decomposes into constituent graphics.

Huh?  I didn't ask about "flattening" or "grouping".  When the import 
command fails, there is no object to select or ungroup.   When it doesn't 
fail, grouping and ungrouping work normally.  I don't think flattening or 
grouping is relevant in the present context.  If you think this is 
relevant, perhaps you could clarify the question.

Re: open+save makes resized text wander

[Scott J. <joh...@ve...>]

>Hi --
>
>I have a drawtool document with the following nasty property:  If I read it in, make a null change (such as creating and then deleting some irrelevant object), and then write it out, the new file is significantly different from the original.  In particular, text that was originally at point A has wandered to a new point B.
>
>Every time I save and re-open the document, the text has wandered farther.
>
>Here is a prescription for reproducibly creating such a document:
> -- create some 18-point text e.g. "asdf"
> -- draw a rectangle around it
> -- align the centers of the rectangle and text
> -- group the rectangle and text
> -- change the fontsize to 24
> -- ungroup
> -- re-align the centers
> -- re-group
> -- save
> -- re-open and observe text is no longer centered
>
>Looking at the file (below) it appears that when the fontsize was changed, the "gs" statement was updated while the "text" statement was not.  It seems this has something to do with the problem.  Using a text editor to change the "18" to a "24" creates a well-behaved file.
>
>============
>
>In my search for a workaround, I stumbled onto the following technique.  It sometimes helps, but I can't guarantee it:
> -- export the document in idraw-format
> -- open the idraw version, and use it to
> -- over-write the drawtool version
>
>
>============================================
>
>drawtool(
>    gs( :fillbg 1 :brush 65535,2 :fgcolor "Black",0,0,0 :bgcolor "White",1,1,1 :nonepat),
>    gs( :fillbg 0 :fgcolor "Black",0,0,0 :font "-*-helvetica-bold-r-normal-*-24-*-*-*-*-*-*-*","Helvetica-Bold",24 :graypat 0),
>    picture(
>        rectangle(164,277,270,341 :gs 0 :transform 1,-0,-0,1,12,33)
>        text(18,"asdf" :gs 1 :transform 1,0,0,1,204,345.5)
>        )
>)


Looks like a problem updating the datum used for serializing the text graphic.  Thanks for pointing this out.

You could enter such information yourself directly into the sourceforge web pages, but I will incorporate what you have sent to the mailing list and me.

Scott Johnston

Fwd: Re: paste special (text) and cut/copy special (text)

[Scott J. <joh...@ve...>]

>Date: Sat, 7 Apr 2001 01:05:21 -0700
>To: John Denker <js...@re...>
>From: Scott Johnston <joh...@ve...>
>Subject: Re: paste special (text) and cut/copy special (text)
>Cc:
>Bcc:
>X-Attachments:
>
>>Hi --
>>
>>Suppose I go to an ordinary text window and copy some complex, 
>>important text to the window manager's clipboard.  I want to paste 
>>that text into an idraw or drawtool document.  According to
>>   http://www.vectaport.com/ivtools/help-wanted.html
>>something like this was "DONE in ivtools-0.7.4"
>>
>>However, it doesn't work when I try it in 0.9.1 using the "gnome" 
>>window manager.
>>
>>As a workaround, I have resorted to the following:  I create an 
>>idraw or drawtool document with a token "placeholder" string.  I 
>>save the document, paste the desired string into place using a text 
>>editor, and then re-open the document in idraw or drawtool.
>
>The copy/paste using the X Window Selection mechanism works for 
>inputting pathnames, URLs, and command lines into and out of the 
>filebrowser dialog boxes: Open, Save/SaveAs, Export, Import, and 
>Print.  That's what that item was talking about I believe.
>
>Scott Johnston

Fwd: Re: color bitmaps saved in idraw format aren't right postscript

[Scott J. <joh...@ve...>]

>Date: Sat, 7 Apr 2001 01:00:21 -0700
>To: John Denker <js...@re...>
>From: Scott Johnston <joh...@ve...>
>Subject: Re: color bitmaps saved in idraw format aren't right postscript
>Cc:
>Bcc:
>X-Attachments:
>
>>Hi --
>>
>>I have some color bitmaps (e.g. GIF or TIFF format) and I want to 
>>incorporate them into my drawings.
>>
>>1) I used idraw to save the drawing in idraw format.  I also used 
>>drawtool to export it in idraw format, with essentially identical 
>>results.  Call this file "foo.ps".  So far so good.
>>
>>2) I can read foo.ps back in using idraw or drawtool and it looks 
>>fine on the screen.  So far so good.
>>
>>3) However, if I try to look at foo.ps using Ghostscript, the 
>>bitmap appears as a grayscale map, not in color.  This is a bug. 
>>It is an exception to the rule that idraw-format files are valid 
>>postscript representations of the drawing.
>
>
>idraw format does store a raster as a printable grayscale, and 
>embeds the true color information in a PostScript comment.
>
>>
>>4) After much fussing around, I tried the _print_ command to create 
>>foo.ps2.  I can look at this file (foo.ps2) using Ghostscript and 
>>it looks fine.  The drawback is reading foo.ps2 back into idraw or 
>>drawtool would lose all the structuring, so I need to keep foo.ps 
>>*and* foo.ps2 around, and need some laborious process to keep them 
>>both up-to-date.
>
>
>The default output format on the Print commands is PostScript (EPS) 
>that is almost like idraw.  A few things have been changed, like 
>color rasters for printing.  When you subsequently import or load 
>this file, drawtool does not recognize it as a idraw format, and 
>invokes pstoedit which flattens it and converts it to idraw format.
>
>>5) In an effort to find a workaround for the problems in the 
>>previous paragraphs, I created a new drawing, bar.ps.  I tried to 
>>import the valid color postscript (foo.ps2).  That did not work. 
>>This is a bug.
>
>
>Can you forward a copy of foo.ps2?
>
>>
>>5a) Normally, if an import fails, the import dialog box will say 
>>"import failed".  But in this case the dialog box just went away, 
>>as if it had completed normally. It just didn't import anything. 
>>This is another bug.
>>
>>5b) It did however print an error message on the terminal, namely
>>         "unknown graphical object ColorRast"
>
>
>Ok, it sounds in this case pstoedit is not getting invoked for some 
>reason, either the file is falsely detected as idraw format, or you 
>don't have pstoedit in your search path.
>
>Perhaps when you see flatten things you mean everything is grouped 
>into object?  Try the Structure/Ungroup command a few times when 
>that one thing is selected, to see if decomposes into constituent 
>graphics.
>
>>
>>==============
>>
>>Suggestions:
>>
>>1) When writing files in idraw format, idraw and drawtool should 
>>save a valid postscript representation of color bitmaps.
>
>
>yeah, why not?  idraw format 14 could make the switch, and backwards 
>compatibility could get worked out.
>
>>
>>2) If for some reason that can't be done, they should at least 
>>print a warning, and suggest using the _print_ command as a 
>>workaround.
>>
>>3) They should be able to import ColorRast objects.
>
>
>yes
>
>>
>>4) If the import fails, the dialog box should consistently indicate this.
>
>yes
>
>
>>============================
>>
>>At 10:01 AM 4/4/01 -0700, Scott Johnston wrote (in a slightly 
>>different context):
>>>I will document these thoughts in the software "tracking" system 
>>>at http://sourceforge.net/projects/ivtools so they don't have to 
>>>be rediscovered yet again in the future.
>>
>>OK.  I can imagine what a software tracking system is supposed to 
>>do.  I tried to look there to see whether the aforementioned bitmap 
>>bug was already on the list.  However, alas, when I tried to use 
>>the system, all I got was
>>         "sf-web1 Could Not Connect to Database: "
>>
>>Also, searches such as
>>   http://www.google.com/search?q=drawtool+color+bitmap
>>were unavailing.
>
>
>that URL should work.  Try it again, maybe you visited during a 
>power blackout  here in California :-)
>
>Scott Johnston

add-custom-tool segmentation fault

[John D. <js...@re...>]

Hi --

Here's a bug:
  -- start drawtool
  -- click on Tools
  -- click on Add Custom Tool
  -- dismiss the popup by hitting the Esc key
  -- observe segmentation fault