Dia ChangeLog report for Mon Aug 26 07:41:14 2002 (UTC)
Snapshots available at http://www.crans.org/~chepelov/dia/snapshots *** Recent ChangeLog entries: --- ChangeLog.previous 2002-08-21 09:24:15.0 +0200 +++ dia-cvs-snapshot/ChangeLog 2002-08-26 09:41:20.0 +0200 @@ -1,3 +1,34 @@ +2002-08-26 Cyrille Chepelov <[EMAIL PROTECTED]> + + * sheets/Makefile.am: enabled intltool-merge translation cache for + sheets. + + * Makefile.am: + * mkauthors-placeholder: + * AUTHORS: revived that file (in a placeholder form) so that + automake stops yelling. + (derived from a patch by Andrew Ferrier <[EMAIL PROTECTED]>) + (Closes: #91144) + + Heh, by the way, thanks Christophe. I feel better now. + +2002-08-25 Christophe Merlet <[EMAIL PROTECTED]> + + * app/command.c: Removed invalid multibyte sequence in Chepelov. + +2002-08-24 Lars Clausen <[EMAIL PROTECTED]> + + * lib/dia_image.c (dia_image_rgb_data): + Bugfixes in image data retrieval. + + * app/render_eps.c: Refactoring of new_*_renderer. + +2002-08-23 Lars Clausen <[EMAIL PROTECTED]> + + * app/render_eps.c: + * lib/dia_image.h: + * lib/dia_image.c: Support for rowstride != width (odd width images) + 2002-08-20 Lars Clausen <[EMAIL PROTECTED]> * lib/paper.c (get_paper_info): Fixed NULL prefs problem. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Strange success story
> Using epsffit to turn an EPS file into PS (the printing gave
> weird headaches) I managed to get some quite nice output.
This reminds me of a tangent about Dia.
Here where I work I use Dia to create the database ERD which is a big,
hairy thing but is a useful document for programmers to look at.
They have little interest in installing Dia (only the DBA does that) -- so
what I do is print the Dia diagram to "output.ps" which thankfully has the
default behaviour of putting the .ps file into the same directory from
whence the .dia file was loaded.
Then I have a script that runs ImageMagick "convert" on the .ps file to
turn it into a .pdf ("convert output.ps output.pdf") which works on
US-Letter sized .ps files (but strangely enough, not on US-Legal size).
Then I email the PDF to whomever wants a copy, and put another copy up on
our intranet site for anyone else who wants it.
Acrobat Reader is a pretty common install. Interestingly, EPS files and
most every other sort of vector graphic file format, including PS, aren't
viewable on Microsoft systems without special software.
--
Tim Ellis
Senior Database Architect
Gamet, Inc.
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
[gimpwin-dev] glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized
James Michael DuPont writes: > Hopefully we can get all the cool gnome apps running under windows Correct me if I am wrong, but doesn't it go like this: GNOME is intended to provide on Unix some of the (high-level) features in Windows, that on Windows are implemented with stuff like COM and OLE (I am really not an expert in this issues, so bear with me if I babble). It does this using CORBA at the low level. Why would one then need to port GNOME as such to Windows? It wouldn't interoperate with native Windows applications anyway, i.e. you could not include some object that interfaces through COM/OLE/whatever in a GNOME container that uses CORBA, or vice versa. Or is it just eye candy you are after ;-) > The problem is with the resource compiler : > gmodule-win32res.lo and > gobject-win32res.lo are dependant on the command : > ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo > which complains that : > Using zero as build number That is just an informational message, not a warning or error. > gmodule-win32res.lo: file not recognized: File format not recognized The .lo file that the lt-compile-resource script produces is a "libtool object file", which actually is a small text file that contains some assignment lines. (Read lt-compile-resource, it's a relatively simple shell script.) At least .lo files are small text files on my setup (on Windows, not cross-compilation). Maybe with cross-compilation from Unix, .lo files are actually symbolic links to the real .o files? Or just .o files with another name? If so, you need to modify the lt-compile-resource script to just do a symlink or rename instead of creating the small text file. Or you can drop the resource file stuff from the makefiles, it's not essential for the DLLs. Why is this resource crap needed at all, you might ask? I want to include version resources in the GLib etc DLLs. (I.e. what you see in Explorer if you right-click a DLL and select Properties:Version.) It's just a hack that has evolved over time. Without feedback, I haven't bothered to try to improve it. As the compile-resource script says: # This is just my ([EMAIL PROTECTED]) idea, if somebody comes up with a # better way to generate version number resources, don't hesitate to # suggest. Please do try. The essential feature the (lt-)compile-resource script provides to me is that after a "make clean", the resource file gets recompiled with a bumped build number. (This happens only if the build number "stamp" file is present, which it is supposed to be only on the "official packager's" machine, so that new releases of "official" DLLs can be recognized from increasing version number resources. Of course, "official" is a silly word to use without offices or officers.) --tml ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Strange success story
On 2002-08-26 at 10:46 -0400, Tim Ellis wrote: > Acrobat Reader is a pretty common install. Interestingly, EPS > files and most every other sort of vector graphic file > format, including PS, aren't viewable on Microsoft systems > without special software. You're probably already aware, but Ghostview etc. do a pretty good job of viewing both EPS and PS on Windows these days. It is of course fair to say that they are probably not as widely installed as Acrobat Reader, but they are free software (speech not beer). Mind you, the people in your environment may not care :) Perhaps it might be wise, on another tangent, to add a --printtofile option or similar to dia so that this could be done from the command line? What do people think? If the consensus is that it's a good idea, I'll add it as an enhancement bug. Regards, Andrew. -- Andrew Ferrier email: [EMAIL PROTECTED] web: http://www.new-destiny.co.uk/andrew/ ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Strange success story
On Mon, 26 Aug 2002, Andrew Ferrier wrote: > On 2002-08-26 at 10:46 -0400, Tim Ellis wrote: > >> Acrobat Reader is a pretty common install. Interestingly, EPS >> files and most every other sort of vector graphic file >> format, including PS, aren't viewable on Microsoft systems >> without special software. > > You're probably already aware, but Ghostview etc. do a pretty > good job of viewing both EPS and PS on Windows these days. It > is of course fair to say that they are probably not as widely > installed as Acrobat Reader, but they are free software (speech > not beer). Mind you, the people in your environment may not > care :) 'Twould be nice to have PDF output as well. Anybody knowledgeable of PDF? > Perhaps it might be wise, on another tangent, to add a > --printtofile option or similar to dia so that this could be > done from the command line? What do people think? If the > consensus is that it's a good idea, I'll add it as an > enhancement bug. I guess that is different from the --export option, since there is no .ps export. Maybe we should have that. -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor "I do not agree with a word that you say, but I | will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket? ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Strange success story
On 2002-08-26 at 15:21 -0500, Lars Clausen wrote: > > You're probably already aware, but Ghostview etc. do a > > pretty good job of viewing both EPS and PS on Windows these > > days. It is of course fair to say that they are probably > > not as widely installed as Acrobat Reader, but they are > > free software (speech not beer). Mind you, the people in > > your environment may not care :) > > 'Twould be nice to have PDF output as well. Anybody > knowledgeable of PDF? It would be non-trivial, I know that much. Personally I'd suggest that if PDF output were to be added, that dia put it through ps2pdf or something instead of doing it itself. Mind you, I've never found any PS to PDF converter entirely satisfactory. > > Perhaps it might be wise, on another tangent, to add a > > --printtofile option or similar to dia so that this could be > > done from the command line? What do people think? If the > > consensus is that it's a good idea, I'll add it as an > > enhancement bug. > > I guess that is different from the --export option, since > there is no .ps export. Maybe we should have that. My thoughts precisely. I'll file it as an enhancement. -- Andrew Ferrier email: [EMAIL PROTECTED] web: http://www.new-destiny.co.uk/andrew/ ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: Strange success story
> 'Twould be nice to have PDF output as well. Anybody knowledgeable of PDF? there are plans to make gnome print not require any gnome libs and work with just gtk. gnome print includes print to file ps/pdf. ask chema for current status. there are several ways to convert PS to pdf, some more elegant than others. i have previously used Ghostscript which includes a program called pdfwrite to convert PS to PDF. For an application like Dia that does not have hyperlinks there is not much of a downside to generating PDF this way. There are other options like pdftex (i think it does LaTeX too or possibly there was a seperate app' called pdflatex). I am sure some one else can suggest many and various better ways to do this. If you really want native PDF support dont let me stop you. Actually do, give me a chance to suggest a different feature you know you want more, you must have mentioned a few, i will dig through the archives if i have to. Sincerely Alan Horkan http://matrix.netsoc.tcd.ie/~horkana/ http://abisource.com "My cat's breath smells like catfood" http://www.maths.tcd.ie/~horkana/rusty.jpg > > --printtofile option or similar to dia so that this could be > > done from the command line? What do people think? If the > > consensus is that it's a good idea, I'll add it as an > > enhancement bug. > > I guess that is different from the --export option, since there is no .ps > export. Maybe we should have that. > > -Lars > > -- > Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| Hårdgrim of Numenor > "I do not agree with a word that you say, but I | > will defend to the death your right to say it." | Where are we going, and > --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket? > ___ > Dia-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/dia-list > ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: [OT]: PS --> PDF converter
> Personally I'd > suggest that if PDF output were to be added, that dia put it > through ps2pdf or something instead of doing it itself. Mind > you, I've never found any PS to PDF converter entirely > satisfactory. I guess I've found ImageMagick to be less than entirely satisfactory, too, but it does a pretty good job. Only two issues I have: 1. It doesn't seem to deal with non-USLetter sized images, even though one of the options you pass to it deals with non-USLetter sized images (?!?!?!). So despite the fact that I might pass "-imageformat A4" it still converts it as USLetter and crops off everything that extends outside those borders. This *MIGHT* be only me... but I doubt it. 2. It doesn't seem to deal with landscape/portrait orientation. Even though the output.ps is right-side-up (as a landscape orientation), the resultant PDF is always sideways (ie: portrait orientation). If Dia were to attempt to incorporate an output-as-PDF function, looking at the ImageMagick "convert" command might be a good place to start. -- Tim Ellis Senior Database Architect Gamet, Inc. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
RE: WIN32 compilation, the spirit of GNU software.
my 2 cents... 1. Hans, thanks for the outstanding work you've done on porting Dia to win32. On behalf of Dia win32 users and developers such as myself, I sincerely hope we don't lose your expertise! 2. Whether its Mike or Hans (or whoever) that has the inclination to make the win32 port easier to build, I'm all for it! I'd offer to help with the win32 port/build environment, but I don't feel that I have the necessary expertise. Maybe I could help with some build documentation, though? 3. What M.DuPont said about encouraging developers to contribute evoked an "AMEN!" from me...fighting to get a win32 build of Dia nearly drove me away. I'm not complaining --rather simply stating that it was a painful experience for an apprentice Dia developer such as myself to get a working win32 (MSVC) build from CVS source. regards, Mike Garnsey --- James Michael DuPont <[EMAIL PROTECTED]> wrote: > > I know what you mean, rob, and I see can see it from > you perspective. > But can you try and see it from mine? > > --- Rob Campbell <[EMAIL PROTECTED]> wrote: > > On Friday, August 23, 2002 9:43 AM, JMD wrote: > > >I just pointed out a problem: I bet Hans realized > that there could > > be a > > >bit a truth in it, and that is why he did what he > did, in my > > opinion. > > > > > >You would just ban me from the list and ignore me > if you really > > thought > > >I was %100 wrong! > > > > I'll go out on a limb and say Hans' action is > instead an indication > > of the > > oft discussed disgust of open source programmers > with users who > > scream, > > "Gimme, gimme, gimme!" In this case, it wasn't > "Gimme this feature" > > but > > "Gimme this tool chain." > > Yes, in a way you are right. I am just asking for > the sources. > > In the beginning, I figured that I would just try it > on my own, > and then I realized that there must be a way to get > the sources already > built. > > So from that perspective, I am just complaining > about having to piece > it all togeather myself. > > > I looked at the GPL itself and was quite suprized > that they were so > explicit about providing the sources, as much as the > rest of you i > imagine. > > Well I am sorry for complaining and spoilling the > fun. > > > Then the implied threats/loaded language > > started > > flying and Hans said, "Fine. Problem remedied. > The binaries are no > > longer > > available." You've since back pedaled on the > implication that Hans > > must be > > holding something back, but the damage is done, > isn't it? > > Yes, and I apologised for it. I am going to get the > port back up and > running. Then I will distribute the sources in such > as way as to > encourage other developers to help, to make it easy > for them to want > and get involved. > > Not only for dia, but for the gcc development as > well, the idea is to > make it easier for people to use these development > tools. To help them > contribute. Having all the source code and > "build-chain" as you call it > will be a BIG step in that direction. > > Again, I am working on a NATIVE port using MING. Not > anything with > cygwin. I will be looking to get the bonobo and > corba interfaces up and > running, also with a perl to orbit to bonobo > intergration like in > GNUMERIC. > > This will make up for the damage I hope. > > If all goes well, even more people will be > contributing to dia, > also because of this little interaction we had. > > Mike > > > = > James Michael DuPont > http://introspector.sourceforge.net/ > > __ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com > ___ > Dia-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/dia-list __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: [Mingw-users] [gimpwin-dev] glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized
> GNOME is intended to provide on Unix some of the (high-level) features > in Windows, that on Windows are implemented with stuff like COM and > OLE (I am really not an expert in this issues, so bear with me if I > babble). It does this using CORBA at the low level. > > Why would one then need to port GNOME as such to Windows? It wouldn't > interoperate with native Windows applications anyway, i.e. you could > not include some object that interfaces through COM/OLE/whatever in a > GNOME container that uses CORBA, or vice versa. > > Or is it just eye candy you are after ;-) GNOME is also a desktop operating environment supported by an applications framework API. I guess the objective would be to have source-level applications compatibility between the platforms. Not sure I like the idea though. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: [gimpwin-dev] glib under mingw32 debian cross compiler, problem with windres : gmodule-win32res.lo: file not recognized: File format not recognized
--- Tor Lillqvist <[EMAIL PROTECTED]> wrote: > James Michael DuPont writes: > > Hopefully we can get all the cool gnome apps running under windows > > Correct me if I am wrong, but doesn't it go like this: > > GNOME is intended to provide on Unix some of the (high-level) > features > in Windows, that on Windows are implemented with stuff like COM and > OLE (I am really not an expert in this issues, so bear with me if I > babble). It does this using CORBA at the low level. The Dia and GNOME projects will benefit from the porting of the corba to windows as done by steven obrien via cygwin. http://homepage.ntlworld.com/steven.obrien2/ The usage of the GNOME orbit corba bindings from perl will be a great benefit, I believe GNUMERIC Supports is as well. > Why would one then need to port GNOME as such to Windows? It wouldn't > interoperate with native Windows applications anyway, i.e. you could > not include some object that interfaces through COM/OLE/whatever in a > GNOME container that uses CORBA, or vice versa. I mean gnome apps, like GNUMERIC, ABI WORD, DIA. > Or is it just eye candy you are after ;-) I am after using the DIA toolkit as a scriptable, browser enabled, graphing layout tool. Also under windows, but more importantly under linux. I only got involved in the port to windows when I wanted to try the python bindings with python 2.2 and noticed that I was in DLL HELL. After writing to hans and dia for help, i decided to follow the instructions and compile, but wanted to do so under cygwin, because most of the gnome libs was ported to windows by steven o'brien. This is when I noticed that it was a pain to get all the sources together. As a service to the community I want to help fix the areas that we all can use. > > The problem is with the resource compiler : > > gmodule-win32res.lo and > > gobject-win32res.lo are dependant on the command : > > ../build/win32/lt-compile-resource gmodule.rc gmodule-win32res.lo > > which complains that : > > Using zero as build number > > That is just an informational message, not a warning or error. > > > gmodule-win32res.lo: file not recognized: File format not > recognized > > The .lo file that the lt-compile-resource script produces is a > "libtool object file", which actually is a small text file that > contains some assignment lines. (Read lt-compile-resource, it's a > relatively simple shell script.) Yes this is the version information for the dlls, I will drop it for now. > > At least .lo files are small text files on my setup (on Windows, not > cross-compilation). Maybe with cross-compilation from Unix, .lo files > are actually symbolic links to the real .o files? Or just .o files > with another name? If so, you need to modify the lt-compile-resource > script to just do a symlink or rename instead of creating the small > text file. Or you can drop the resource file stuff from the > makefiles, > it's not essential for the DLLs. > > Why is this resource crap needed at all, you might ask? I want to > include version resources in the GLib etc DLLs. (I.e. what you see in > Explorer if you right-click a DLL and select Properties:Version.) > > It's just a hack that has evolved over time. Without feedback, I > haven't bothered to try to improve it. As the compile-resource script > says: > > # This is just my ([EMAIL PROTECTED]) idea, if somebody comes up with a > # better way to generate version number resources, don't hesitate to > # suggest. > > Please do try. The essential feature the (lt-)compile-resource script > provides to me is that after a "make clean", the resource file gets > recompiled with a bumped build number. (This happens only if the > build > number "stamp" file is present, which it is supposed to be only on > the > "official packager's" machine, so that new releases of "official" > DLLs > can be recognized from increasing version number resources. Of > course, > "official" is a silly word to use without offices or officers.) Thanks for this explaination! Zour help is greatly appreciated! All i need to do now is debug the linker options, it seems like I got all of glib to compile... now I have to get it to link! mike = James Michael DuPont http://introspector.sourceforge.net/ __ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Re: thanks for tedia2sql
> Thanks for tedia2sql, I used it with pgsql and it's > very useful. Great! I've had about five reports of tedia2sql working. Two people actively trying to get bugs solved for them, both of which seem to've worked their way to resolution. One person trying to add a large feature set to tedia2sql (Class inheritance). Also a proposed large feature set which I'm still unsure how to handle, involving using special RDBMS constructs like CASCADE. Just a reminder to the lists, tedia2sql is still under development and currently stable. Main web page (http://tedia2sql.tigris.org) was updated to require Dia 0.90 because there's a problem with UML Components under 0.88.1. > About your changes to Dia to show more connect dots, > could those be merged in main Dia version? I've submitted two patches to the maintainers and, as far as I'm aware, the first was accepted but the second, which I feel is technically superior & which replaces the first patch, has not. In any case, current Dia CVS has an ability to use more connection points on the top & bottom... IF YOU RECOMPILE DIA FROM SOURCE. I've... begged?... the Dia maintainers to make more connection points on UML classes the standard behaviour and submitted the second patch to make sure this wouldn't harm legacy users of Dia. Getting more connection points is a FAQ, so I figure it can't be only me that wants it. The general consensus seems to be Dia will continue to have "8" connection points UNLESS YOU RECOMPILE. -- Tim Ellis Senior Database Architect Author, tedia2sql (http://tedia2sql.tigris.org) ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
Question about the polyline object...
Gday,
First up, thanks for creating a great tool. I am currently using it for
schematic diagrams and I find dia quite usefull.
However, the niceties aside, I am trying to get the xfig importer back
into shape but I have run across a snag. Currenly the xfig importer
doesnt *seem* to import xfig polylines. The reson, as it appears to me,
is that there doesnt seem to be an appropriate API to permit the loading
of the actual polyline points into the polyline object. I understand how
to create an instance of a polyline (using
ObjectType->ops->Create(...) etc) BUT, loading the actual points into
the object seems to be impossible. All I get is the two default points,
one at the point given to create() and another at px+1 and py+1.
The same problem seems to apply to beziergons and just about any object
that can have a variable number of points.
So my question, have I missed something? Is there a specifical call to
manipulate the points stored in an object? If not, then what are the
current plans on the table for implementing point manipulation
interfaces in dia objects?
Secondly, I have also attached a patch to 0.88.1 to permit the setting of
the zigzag line orientation. I have already sent this patch to Alex
Larsson but I have not recieved any comment on it, so I am sending it to
the list.
'Ave fun...
Cheers Mik.
diff -ur dia-0.88.1/lib/orth_conn.c dia-0.88.1mv/lib/orth_conn.c
--- dia-0.88.1/lib/orth_conn.c Mon Mar 26 11:05:21 2001
+++ dia-0.88.1mv/lib/orth_conn.cSun Aug 25 15:07:26 2002
@@ -30,9 +30,13 @@
enum change_type {
TYPE_ADD_SEGMENT,
- TYPE_REMOVE_SEGMENT
+ TYPE_REMOVE_SEGMENT,
+ TYPE_ORIENT_VERT,
+ TYPE_ORIENT_HORIZ
};
+static enum change_type orthconn_orientation = TYPE_ORIENT_HORIZ;
+
static ObjectChange *
midsegment_create_change(OrthConn *orth, enum change_type type,
int segment,
@@ -88,6 +92,17 @@
remove segment */
};
+static ObjectChange *
+orient_change_create(OrthConn *orth, enum change_type change);
+
+struct OrientChange
+{
+ObjectChange obj_change;
+enum change_type type;
+int applied;
+enum change_type previous_value;
+};
+
static void set_midpoint(Point *point, OrthConn *orth, int segment)
{
@@ -399,18 +414,33 @@
obj->handles[2] = orth->handles[2];
/* Just so we have some position: */
- orth->points[0] = *startpoint;
- orth->points[1].x = startpoint->x;
- orth->points[1].y = startpoint->y + 1.0;
- orth->points[2].x = startpoint->x + 1.0;
- orth->points[2].y = startpoint->y + 1.0;
- orth->points[3].x = startpoint->x + 2.0;
- orth->points[3].y = startpoint->y + 1.0;
-
- orth->orientation[0] = VERTICAL;
- orth->orientation[1] = HORIZONTAL;
- orth->orientation[2] = VERTICAL;
-
+ if (orthconn_orientation == TYPE_ORIENT_HORIZ)
+ {
+orth->points[0] = *startpoint;
+orth->points[1].x = startpoint->x;
+orth->points[1].y = startpoint->y + 1.0;
+orth->points[2].x = startpoint->x + 1.0;
+orth->points[2].y = startpoint->y + 1.0;
+orth->points[3].x = startpoint->x + 2.0;
+orth->points[3].y = startpoint->y + 1.0;
+
+orth->orientation[0] = VERTICAL;
+orth->orientation[1] = HORIZONTAL;
+orth->orientation[2] = VERTICAL;
+ } else
+ {
+orth->points[0] = *startpoint;
+orth->points[1].x = startpoint->x + 1.0;
+orth->points[1].y = startpoint->y;
+orth->points[2].x = startpoint->x + 1.0;
+orth->points[2].y = startpoint->y + 1.0;
+orth->points[3].x = startpoint->x + 1.0;
+orth->points[3].y = startpoint->y + 2.0;
+
+orth->orientation[0] = HORIZONTAL;
+orth->orientation[1] = VERTICAL;
+orth->orientation[2] = HORIZONTAL;
+ }
orthconn_update_data(orth);
}
@@ -662,6 +692,26 @@
return change;
}
+ObjectChange *
+orthconn_orient_vert(OrthConn *orth, Point *clicked)
+{
+ObjectChange *change = NULL;
+
+change = orient_change_create(orth, TYPE_ORIENT_VERT);
+change->apply(change, (Object *) orth);
+return change;
+}
+
+ObjectChange *
+orthconn_orient_horiz(OrthConn *orth, Point *clicked)
+{
+ObjectChange *change = NULL;
+
+change = orient_change_create(orth, TYPE_ORIENT_HORIZ);
+change->apply(change, (Object *) orth);
+return change;
+}
+
static void
delete_point(OrthConn *orth, int pos)
{
@@ -790,6 +840,8 @@
HANDLE_MOVE_ENDPOINT);
}
break;
+default:
+break;
}
}
@@ -831,6 +883,8 @@
if (change->cp)
object_connect(obj, change->old_end_handle, change->cp);
break;
+default:
+break;
}
change->applied = 0;
}
@@ -903,6 +957,8 @@
orth->points[change->segment].y = change->points[0].y;
}
break;
+default:
+break;
}
}
@@ -931,6 +987,8 @@
insert_handle(orth, change->segment, change->handles[0],
FLIP_ORIENT(orth->orientation[change->segment-1]) );
break;
+default:
+b
Re: [OT]: PS --> PDF converter
On lun, 2002-08-26 at 20:44, Tim Ellis wrote: > > Personally I'd > > suggest that if PDF output were to be added, that dia put it > > through ps2pdf or something instead of doing it itself. Mind > > you, I've never found any PS to PDF converter entirely > > satisfactory. > > I guess I've found ImageMagick to be less than entirely satisfactory, too, > but it does a pretty good job. Only two issues I have: [...] > If Dia were to attempt to incorporate an output-as-PDF function, looking > at the ImageMagick "convert" command might be a good place to start. AFAIK, the ImageMagick support for PDF, PS and EPS is done thru GhostScript. So why using ImageMagick convert instead of ps2pdf which is a GhostScript utility ? Hub -- Job-less AbiWord hacker. - http://www.teaser.fr/~hfiguiere/ Cell phone: +33 6 18 01 42 11 GPG fingerprint: 6C44 DB3E 0BF3 EAF5 B433 239A 5FEE 05E6 A56E 15A3 signature.asc Description: This is a digitally signed message part
Re: Question about the polyline object...
Le Tue, Aug 27, 2002, à 01:47:21PM +1000, Michael H. Voase a écrit: > The same problem seems to apply to beziergons and just about any > object that can have a variable number of points. I suggest you have a look at the recent CVS -- or at the very least, to 0.90, which is significantly different from 0.88.1. Looking at the code in CVS plug-ins/xfig/xfig-import.c, it does seem to pass to ->create() a structure holding a number of points and an array thereof. > So my question, have I missed something? Is there a specifical call > to manipulate the points stored in an object? If not, then what are the > current plans on the table for implementing point manipulation > interfaces in dia objects? polyconn_add/remove_point() can probably do what you need (don't forget to do something with the returned ObjectChange*) > Secondly, I have also attached a patch to 0.88.1 to permit the > setting of the zigzag line orientation. I have already sent this patch to > Alex Larsson but I have not recieved any comment on it, so I am sending it > to the list. Lars Clausen recently did a lot of stuff with the ZZ line orientations. I strongly suggest you download CVS and check first whether your patch still applies (both in the patch(1) sense and featurewise). Alex has stepped down from maintainership a while ago; the best place to send patches is here. (it wouldn't be bad if patches against en_GB.po were sent separately from feature patches) -- Cyrille -- Grumpf. ___ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
