I joined this list to ask about these features for Dia:
* beziergon: in the middle click menu or anywhere else- there seems
to be no way to convert a segment to a line (instead of a
curve).
The usual symmetric, smooth and cusp commands are there- but
there is no way to a
thanks for the reply, very informative.
>The filling options are limited because Dia isn't a vector drawing
program,
>it's a diagramming program. For a vector drawing program, try Sketch
>http://sketch.sourceforge.net/> or Gyve
http://www.gyve.org/>.
Despite the end purposes being different,
>That's one problem with standards (UI or otherwise).
>Why shouldn't my graphics application use [a-zA-Z] as
>efficient, intuitive shortcuts, just because a word
>processor can't?
my word processor (vim) does just that :)
___
Dia-list mailing list
>> Once the render interface settles, dia could do all the fancy font
>> rendering with rotation/scaling/offsetting directly with the xserver
>> or through the GDI, and avoid the mess that open office and abiword
>> got into (wrt fonts)
>Yeah, once that settles. Unfortunately, we don't know whe
>I seems I am officially in charge of font handling now, due to trying
to
>hack up FreeType support:) I'm trying to get away from the frankly
>horribly hard-coded font list in there now, but I'm having trouble with
the
>ctual rendering for FreeType. I'm guessing the trouble you see lies in
>suc
>I have no idea how to do non-ascii input[1], much less how to handle it
in
>a program. For characters typed directly from the keyboard, I think it
>should work (any confirmation), but we don't handle multi-key input.
there are things such as XIM, etc, which are supposed to handle this
at the
>I don't know if it helps but I have to tell you and Lars
>that I am able to get the correct glyphs from different GTK
>apps like gedit and the gnome Env itself, so it seems to be
>more a problem of the widget used in DIA. I'm wright? Leo.
just for curiosity, do you have the problem in all parts
>I see the problem, in several different incarnations. When using
freetype,
>it doesn't render the characters right, but they seem to go in there.
When
>I try to save, it loops with 'xmlEncodeEntitiesReentrant : input not
UTF-8'.
>I can't try without UTF-8, as the --disable-unicode settin
>I wonder how practical it would be for multiple people to
>work on the same Dia file simultaneously, merging there
>changes through CVS? I suppose one could even optimize
>the file format for that. Just a thought.
your main problem would be conflicts: youd need a conflict
resolution system
>Diff doesn't actually know anything about the semantics
>of the language, though, right? Which is why CVS works
>seamlessly with C, Pascal, or readme files. I think it
>is line oriented. The only thing it cares about when
>merging two changes derived from the same revision of a
>file is their
>I was wondering why all strings are enclosed with '#' in my dia files
(UML objects). Thanks in
>advance.
I as well am annoyed by that, to my thinking the default XML
encoding is UTF-8, which is more than enough for internationalization,
which I believe had something to do with it...
__
I downloaded the rc1 windows version (im at work, and no have visio
installed)
Ive noticed that dia is not accepting unicode input from the GUI. (this
may be
a limitation in the version of gtk as built with that version?)
that got me wondering what the state of utf-8 support is within dia at
th
>Uhmm. How do you expect 'unicode input' to work ? Using those
>funny Umlauts printed at least at german keyboards does work
>finally and Alt-Numeric Keyboard Keys does work as well ...
hrm, maybe its the font available: im using a regular us/english
setup, and if i insert some japanese utf-8
tiny example diagram attached:
does this attached diagram show up for anyone
in their version of dia. It should contain
a flowchart box with:
"begin:運多教, end"
inside it
temp.dia
Description: temp.dia
thx for the reply Loli,
>> tiny example diagram attached:
>> does this attached diagram show up for anyone
>> in their version of dia. It should contain
>> a flowchart box with:
>> "begin:XXX, end"
>I dont know if the diagram I saw is just what you excepted: there are
>some differences betw
>To display glyphs on a screen, you need that the whole process
>is able to process said glyphs (and much more: xfs, X11, etc.).
Currently,
>dia 0.90-RC# is able to process UTF-8 data; however, one of its modules
>can't. That module is called gtk.
ok, thanks for the reply Cyrille.
I was suspic
>I see the problem. This is a very important bug, and I wish I knew
more
>about encodings and stuff so that I could fix it. Make sure to submit
a
>bug report on it. In fact, there should probably be several separate
>reports: One that Dia doesn't assume that files without specific
encoding
>is
>> > It may be sufficient for dia to only support utf-8. You generally
dont
>> > create dia files by hand, so you probably shouldnt care which
encoding
>> > they are in.
>>
>> We need to support non-utf8 encodings for two reasons: Backwards
>> compatibility and diagrams created by other progra
>I guess this issue is over ?
Well, The latin-1 diagram still makes v0.90 for windos segfault :)
Error: file font.c line 1178: assertion Failed (name!=NULL)
abroting...
___
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo
>I wish the gtk-win32 maintainers were bold enough to add a "render
rotated text"
>API function (which shouldn't be very hard to implement on Win32), and
>implement it on X as a g_warning("FIXME: X sucks at rotating fonts").
Just
>to get the things in motion.
This should not be hard under gtk2,
>My idea was to write a program to help CS students from Barcelona's CS
>Faculty (FIB) to choose among the different optional subjects.
Rather try to hard-code all that information into an application such
as dia, you might wish to consider creating a simple cgi application,
with a databse b
21 matches
Mail list logo
