headers
Ted Gould | 1 Sep 2009 05:16
Favicon
Gravatar

Re: Re : Inkscape logo on a book cover

On Mon, 2009-08-31 at 13:36 +0000, Nicolas Dufour wrote:
> > From: "mail@..." <mail@...>
> > Is the logo licensed under the same license model?
> 
> I've had the same question some times ago. See:
> http://www.nabble.com/Inkscape-logo-license-td22659124.html#a22696315
> http://www.nabble.com/Inkscape-logo-Public-Domain--Can%27t-be-right.-td21323820.html#a21331853
> 
> There's also a bug report about it:
> https://bugs.launchpad.net/inkscape/+bug/345778
> 
> Ted, do you have some news?

No news really.  I sat down with the lawyer from the SFLC at the Gran
Canaria Desktop Summit and went through some ideas on what we wanted to
see in the Trademark agreement (basically, use it to represent Inkscape
and we're cool) and she was taking it back to lawyer it up before
sending it to the board for their comments/approval.  She hasn't gotten
back to me yet on that, I'll ping her again.

		--Ted

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply | 6 comments |
headers
Ted Gould | 1 Sep 2009 05:18
Favicon
Gravatar

Re: Re : Inkscape 0.47pre2

On Sat, 2009-08-29 at 15:25 +0000, Nicolas Dufour wrote:
> > On 24/8/09 16:57, Ted Gould wrote:
> > > On Mon, 2009-08-24 at 00:10 -0700, Josh Andler wrote:
> > >> Thanks for doing this! For the record, I believe that the
> > >> calligraphic-presets.h was created to make those translatable, as they
> > >> weren't before.. I may be wrong, but could swear that was why.
> > > 
> > > I don't have the file anymore in my trunk checkout... so that's why I
> > > removed it.  Is that an error?
> > 
> > see Bug #327533 in Inkscape: “Calligraphy presets are not translatable”:
> 
> I confirm it was created for translations. And it is still in the trunk (http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/ui/dialog/calligraphic-presets.h?view=log).
> Could someone (Jon, Bulia?) re-enable it in POTFILE.in so that the presets are translatable again?

I can't really look at this now as my laptop is in for repair, but I'd
have to say that I'm a little concerned about an .h file that isn't
included anywhere.  There's probably a better fix.

What do the release managers want there, put the file back just to
reduce risk or should we look for the "final fix"?

		--Ted

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
(Continue reading)

Permalink | Reply | 3 comments |
headers
Michael Wybrow | 1 Sep 2009 02:15
Picon
Picon
Favicon

Re: [Inkscape-devel] Inkscape 0.47pre2


On 31/08/2009, at 6:11 PM, Alexandre Prokoudine wrote:
>
> Is anyone doing a Mac/native GTK+ build for pre2?
>
> Sorry for pushing, but it's a week since pre2 was released and all we
> have is sources :(

I'm working on a universal package that will run on Leopard and Snow  
Leopard.

I don't think it is worth creating another gtk-native-mac build,  
unless anyone wants to start actively working on the things I  
mentioned about the one I made for pre0 -- the gtk-native-mac version  
is going to require a fair amount of attention before it can become  
the main supported one over the x11-based version.

Work on the universal x11-based package for Mac is a little slow...  
partly because I am quite busy with work, and partly because of the  
added complication of testing an additional version of the operating  
system (Snow Leopard 10.6).

Anyway, Mac builds are coming and haven't been forgotten.  If anyone  
else with mac packaging experience wants to contribute to the effort,  
it would be useful to look at some of the outstanding issues I haven't  
got to yet, like the dictionary bundling or the DBUS bundling/startup  
(might be similar to what GIMP has).  If so, let me know.

Cheers,
Michael
(Continue reading)

Permalink | Reply | 28 comments |
headers
Jon A. Cruz | 1 Sep 2009 06:55
Gravatar

Re: [Inkscape-devel] Inkscape 0.47pre2

On Tue, 2009-09-01 at 10:15 +1000, Michael Wybrow wrote:
> 
> I'm working on a universal package that will run on Leopard and Snow  
> Leopard.
> 

Also... is there anyone out there who can look into doing a build of
0.46 for Snow Leopard?

At the moment it seems to be broken. However, if we can get the older
0.46 working on Snow Leopard, then we can one-up some of the current
commercial companies who have declared no ongoing support for older
versions of the software.

Of course, I'm not suggesting we take away from getting 0.47 out. It is
just that we have a nice window of opportunity to show why Open Source
in general can be better than proprietary.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply | 0 comments |
headers
Nicolas Dufour | 1 Sep 2009 07:00
Picon
Favicon
Gravatar

Re : Re : Inkscape 0.47pre2

> De : Ted Gould <ted@...>

> À : Nicolas Dufour <nicoduf@...>
> > I confirm it was created for translations. And it is still in the trunk 
> (http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/ui/dialog/calligraphic-presets.h?view=log).
> > Could someone (Jon, Bulia?) re-enable it in POTFILE.in so that the presets are 
> > translatable again?
> 
> I can't really look at this now as my laptop is in for repair, but I'd
> have to say that I'm a little concerned about an ..h file that isn't
> included anywhere.  There's probably a better fix.

Yes, probably. I used a .h file because that's the way filters are also translated, and it was easy to set up.
If .h is confusing in this case, we could find another file extension.

> What do the release managers want there, put the file back just to
> reduce risk or should we look for the "final fix"?

Regards,
--
Nicolas

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply | 2 comments |
headers
Peter Moulder | 1 Sep 2009 02:39
Picon
Picon
Favicon

Re: Broken feImage and lib2geom matrix inversion

On Sun, Aug 30, 2009 at 03:20:44PM +0200, Tavmjong Bah wrote:

> > ... https://bugs.launchpad.net/inkscape/+bug/382313 ...
> > More specifically, Geom::Matrix.inverse() returns an incorrect
> > matrix.
> 
> In Geom::Matrix::inverse() the matrix determinate is calculated and then
> compared to the constant EPSILON which is defined as 10^-5 (in coord.h).
> If it is less than EPSILON the matrix is set to unity. This EPSILON is
> clearly way too large for use in inverse().

njh thinks that EPSILON shouldn't be smaller than 1e-8 with the current code
& callers.

Sorry for not checking myself (I'm just about to leave), but is changing
EPSILON to 1.5e-8 enough to make this test case work?

pjrm.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply | 5 comments |
headers
Tavmjong Bah | 1 Sep 2009 08:39
Picon
Favicon
Gravatar

Re: Broken feImage and lib2geom matrix inversion

On Tue, 2009-09-01 at 10:39 +1000, Peter Moulder wrote:
> On Sun, Aug 30, 2009 at 03:20:44PM +0200, Tavmjong Bah wrote:
> 
> > > ... https://bugs.launchpad.net/inkscape/+bug/382313 ...
> > > More specifically, Geom::Matrix.inverse() returns an incorrect
> > > matrix.
> > 
> > In Geom::Matrix::inverse() the matrix determinate is calculated and then
> > compared to the constant EPSILON which is defined as 10^-5 (in coord.h).
> > If it is less than EPSILON the matrix is set to unity. This EPSILON is
> > clearly way too large for use in inverse().
> 
> njh thinks that EPSILON shouldn't be smaller than 1e-8 with the current code
> & callers.
> 
> Sorry for not checking myself (I'm just about to leave), but is changing
> EPSILON to 1.5e-8 enough to make this test case work?

The inverse() function is used to find the bounding box of the image in
drawing coordinates. Setting EPSILON to 1.5e-8 would make this test case
work but would cause trouble if anybody wanted to use the feImage filter
with an image greater than 8000x8000 px (not common... but you never
know). (There is the question of why a matrix inversion is necessary in
the first place to find the bounding box but that is a separate issue
for a filters expert.)

Fundamentally, I think having one value of EPSILON used everywhere in
lib2geom is wrong as the way it is used is different in different
functions. Not knowing much about lib2geom, I would guess that using
EPISLON^2 in the matrix inverse function would be more reasonable.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Peter Moulder | 1 Sep 2009 10:08
Picon
Picon
Favicon

Re: Broken feImage and lib2geom matrix inversion

On Tue, Sep 01, 2009 at 08:39:35AM +0200, Tavmjong Bah wrote:

> The inverse() function is used to find the bounding box of the image in
> drawing coordinates. Setting EPSILON to 1.5e-8 would make this test case
> work but would cause trouble if anybody wanted to use the feImage filter
> with an image greater than 8000x8000 px (not common... but you never
> know). (There is the question of why a matrix inversion is necessary in
> the first place to find the bounding box but that is a separate issue
> for a filters expert.)

If we're literally talking px in the CSS sense (1px = 1/2688 of expected
viewing distance) then it is indeed OK not to work on images wider than about
4/3 of viewing distance (3584px) wide.  The number 4/3 is one I just made up
based on trying to look at a picture and deciding how far away I need to move
from a picture for it to be comfortable to look at the whole picture;
certainly 8000px (112°) is too big for me to take in the whole picture,
even though my peripheral vision extends beyond that.

Of course it's still useful to have an error margin for e.g. zoom-related uses,
preferably an error margin bigger than a factor of 8000/3584, it's just a
question of what costs we're willing to take to do so.

> Fundamentally, I think having one value of EPSILON used everywhere in
> lib2geom is wrong as the way it is used is different in different
> functions.

Agreed.  Presumably it arises because it's difficult to come up with the right
number to use :) .

Anyway, note that njh has now changed the calculation a little (in upstream
(Continue reading)

Permalink | Reply | 3 comments |
headers
EnzoAeneas | 1 Sep 2009 10:15
Picon

[ocal-browser-discuss] Yes, it is still alive!

Please check out the two documents/posts and leave comments!

http://groups.google.com/group/ocal-browser-discuss/web/plan-for-gui

http://groups.google.com/group/ocal-browser-discuss/web/ocal-browser-object-diagram-comments-please


---------- Forwarded message ----------
From: EnzoAeneas <enzoaeneas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Sat, Aug 29, 2009 at 4:18 AM
Subject: [ocal-browser-discuss] Yes, it is still alive!
To: ocal-browser-discuss <ocal-browser-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>



Sorry, but like many of you I have a job that pays my bills and I
haven't had much time to devote to this.
But I have not abandoned hope!

Here is the direction that I want to take this:

Python - gotta love dynamic languages.

XUL instead of PyGTK or PyQt. The native SVG support will make things
much easier!
Plus a declarative UI will be faster to build and debug.

Using Mozilla XulRunner as a platform will also give benefits:

Settings/preference system including GUI support.
SQLite support abstracted by a Storage API.
Ability to leverage web-based technologies in conjunction with the
native XUL support gives many options for the UI and  XML/RDF
templating can reduce the amount of code needed to display information
about each image.
Basic extensions framework allowing for different features to be
implemented as pluggable modules rather than new builds.
Builtin updates system.
With a mature browser component, users can surf OpenClipArt.org and
pick clipart to download into their local repository.
JSON support, Web Services support, XMLHttpRequest, etc will make
ccHost integration much easier.

Not to mention, all of the AJAX code out there that manipulates images
can be made leveraged for more advanced features because the
limitations of the browser sandbox will be lifted for extension code.

What cannot be done using the facilities provided by Gecko/XulRunner,
can either be done using an appropriate python library or integrating
with Java (JavaXPCOM).

HTML 5 and Xforms support may yield future benefits. In the end, the
progression of the web and related technologies will allow for greater
improvements in functionality and implementation.


Let me know if you have any ideas. I will try to get a data model and
Base API out soon.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ocal-browser-discuss" group.
To post to this group, send email to ocal-browser-discuss-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to ocal-browser-discuss+unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/ocal-browser-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---


<div>
<p>Please check out the two documents/posts and leave comments!<br><br><a href="http://groups.google.com/group/ocal-browser-discuss/web/plan-for-gui">http://groups.google.com/group/ocal-browser-discuss/web/plan-for-gui</a><br><br><a href="http://groups.google.com/group/ocal-browser-discuss/web/ocal-browser-object-diagram-comments-please">http://groups.google.com/group/ocal-browser-discuss/web/ocal-browser-object-diagram-comments-please</a><br><br><br></p>
<div class="gmail_quote">---------- Forwarded message ----------<br>From: EnzoAeneas <span dir="ltr">&lt;<a href="mailto:enzoaeneas@...">enzoaeneas@...</a>&gt;</span><br>

Date: Sat, Aug 29, 2009 at 4:18 AM<br>Subject: [ocal-browser-discuss] Yes, it is still alive!<br>To: ocal-browser-discuss &lt;<a href="mailto:ocal-browser-discuss@...">ocal-browser-discuss@...</a>&gt;<br><br><br><br>
Sorry, but like many of you I have a job that pays my bills and I<br>
haven't had much time to devote to this.<br>
But I have not abandoned hope!<br><br>
Here is the direction that I want to take this:<br><br>
Python - gotta love dynamic languages.<br><br>
XUL instead of PyGTK or PyQt. The native SVG support will make things<br>
much easier!<br>
Plus a declarative UI will be faster to build and debug.<br><br>
Using Mozilla XulRunner as a platform will also give benefits:<br><br>
Settings/preference system including GUI support.<br>
SQLite support abstracted by a Storage API.<br>
Ability to leverage web-based technologies in conjunction with the<br>
native XUL support gives many options for the UI and &nbsp;XML/RDF<br>
templating can reduce the amount of code needed to display information<br>
about each image.<br>
Basic extensions framework allowing for different features to be<br>
implemented as pluggable modules rather than new builds.<br>
Builtin updates system.<br>
With a mature browser component, users can surf OpenClipArt.org and<br>
pick clipart to download into their local repository.<br>
JSON support, Web Services support, XMLHttpRequest, etc will make<br>
ccHost integration much easier.<br><br>
Not to mention, all of the AJAX code out there that manipulates images<br>
can be made leveraged for more advanced features because the<br>
limitations of the browser sandbox will be lifted for extension code.<br><br>
What cannot be done using the facilities provided by Gecko/XulRunner,<br>
can either be done using an appropriate python library or integrating<br>
with Java (JavaXPCOM).<br><br>
HTML 5 and Xforms support may yield future benefits. In the end, the<br>
progression of the web and related technologies will allow for greater<br>
improvements in functionality and implementation.<br><br><br>
Let me know if you have any ideas. I will try to get a data model and<br>
Base API out soon.<br><br>
--~--~---------~--~----~------------~-------~--~----~<br>
You received this message because you are subscribed to the Google Groups "ocal-browser-discuss" group.<br>
To post to this group, send email to <a href="mailto:ocal-browser-discuss <at> googlegroups.com">ocal-browser-discuss@...</a><br>
To unsubscribe from this group, send email to <a href="mailto:ocal-browser-discuss%2Bunsubscribe@...">ocal-browser-discuss+unsubscribe <at> googlegroups.com</a><br>
For more options, visit this group at <a href="http://groups.google.com/group/ocal-browser-discuss?hl=en" target="_blank">http://groups.google.com/group/ocal-browser-discuss?hl=en</a><br>
-~----------~----~----~----~------~----~------~--~---<br><br>
</div>
<br>
</div>
Permalink | Reply | 0 comments |
headers
~suv | 1 Sep 2009 11:17
Picon

Re: [Inkscape-devel] Inkscape 0.47pre2

On 1/9/09 02:15, Michael Wybrow wrote:
> Anyway, Mac builds are coming and haven't been forgotten.  If anyone  
> else with mac packaging experience wants to contribute to the effort,  
> it would be useful to look at some of the outstanding issues I haven't  
> got to yet, like the dictionary bundling or the DBUS bundling/startup  
> (might be similar to what GIMP has).  If so, let me know.

1) I have had a look at the spell check dictionary issue, but got stuck
when it seemed to fail in an area outside of my abilities (C++ code
reading $ASPELL_CONF to get the list of available spell check
dictionaries for the 'Spell Check' page in the preferences dialog)

Bug #396322 in Inkscape: “Spell checker crashes the OS X package”:
<https://bugs.edge.launchpad.net/inkscape/+bug/396322>

2) GIMP on OS X: dbus-binaries are included in the application bundle
and called by the launcher script before exec'ing gimp-bin

launcher scripts in the app-skeleton:
<http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/Gimp-app-template/Contents/Resources/bin/gimp?revision=6&view=markup>
<http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/Gimp-app-template/Contents/Resources/bin/gimp-remote?revision=6&view=markup>

MacPorts configuration and portfiles+patches for gimponosx:
<http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/GimpPorts/>

Script files for building & bundling
<http://gimponosx.svn.sourceforge.net/viewvc/gimponosx/scripts/>

I do not have a lot of MacPorts experience and haven't built GIMP
myself, but it seems important to note that GIMP on OS X (Gimp.app) only
builds with a separate MacPorts tree, as the application being
relocatable depends not on DYLD_LIBRARY_PATH for the included shared
libs but on the MacPorts prefix pointing to a symbolic link in /tmp,
which must exist at build and (recreated every time) at run time.

D-Bus would be nice to have but IMHO it is not a blocker for 0.47 as the
D-Bus API for Inkscape still lives in a separate branch - or are there
plans to include it in 0.47 already?

3) Did you have a look at the proposed fixes for the ImageMagick raster
effects? <https://bugs.edge.launchpad.net/inkscape/+bug/390024>

I cannot offer to contribute more due to lack of mac packaging
experience - anything else that could be helpful besides trying to
triage new / unconfirmed osx bugs on launchpad?

hth, ~suv

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Permalink | Reply | 0 comments |

Gmane