Downloads Exception
by Martin Owens
Devs,
Launchpad have allowed my request for a downlaods size exception to
expire. (which I'm not happy about) But this does leave us with an
important todo item, we must find a new home for our downloads before
the 0.91 release because of the very unsafe nature that sourceforge has
become.
We do know these things:
* Launchpad can only host our windows and source packages, Max OSX is
too large.
* Our website would not cope with our download traffic.
* We have no mirrors, official or otherwise.
If you have any ideas how we can solve this problem, please discuss
here.
Martin Owens,
8 years, 5 months
remove of DPISWITCH extension from tunk
by Jabiertxo Arraiza Cenoz
Hello i want to remove the DPISWITCH extension from trunk.
Why? I find displacements problems in clip-mask, -inverse displacement-.
So because we are thinking to handle the DPI on export/print...
If DPI is customizable on export, maybe is a good point to allow by
default 96 but a free input box.
Regards.
8 years, 6 months
Visual Align interaction proposal
by Fernando Cuenca Margalef
Hi folks,
I've seen the nice visual alignment development, I will love it!
But I find the interactionvery overloaded of buttons in the video. And I
think it becames so complex and not coherent with the old functions.
I send you attached an alternative proposal to implement such nice
feature in next Inkscape version. Considering the simplest way and more
coherent with Inkscape.
Thanks to all for the great work with this amazing piece of software,
Fernando
8 years, 6 months
Fwd: Re: Roadmap brainstorming for 0.92 and forward
by Liam White
---------- Forwarded message ----------
From: "Liam White" <inkscapebrony@...400...>
Date: Nov 29, 2014 2:18 PM
Subject: Re: [Inkscape-devel] Roadmap brainstorming for 0.92 and forward
To: "Alexander Brock" <a.brock@...2965...>
Cc:
> What's the difference between an SPObject and an SPItem? Which svg
> elements translate into an SPItem, which into an SPObject?
>
> Alexander
SPItems are generally visible objects.
SPObjects that are not SPItems are the rest of the objects and are not
renderable.
8 years, 6 months
Volunteers needed: 0.91 Release Marketing
by Bryce Harrington
Hi all,
As the developers put the final touches on the 0.91 release, it's high
time to plan a media blitz to get this announced to all our users.
I'd like to recruit and organize a formal team to do marketing for
Inkscape. This'll involve writing copy, planning announce strategies,
notifying news sites, coordinating with parallel fundraising efforts,
and more. We'll be organizing an online IRC meeting soon to coordinate
these activities. Sound like fun?
Ryan Lerch, Josh Andler, and myself are already signed on; we've been
through the release announcement process before so we're old hands. But
we're looking for new ideas and fresh blood, so that we can go beyond
what we've achieved in the past.
Interested? Reply to this email and introduce yourself!
Bryce
P.S. Inkscape's past marketing teams have left us a wealth of notes we
can use to build from. Two items in particular:
http://wiki.inkscape.org/wiki/index.php/Announcing_Releases
http://wiki.inkscape.org/wiki/index.php/Inkscape_coverage
8 years, 6 months
Download method, roadmap brainstorm, percentage in SVG root and objects, units
by Jelle Mulder
Hello people,
On behalf of your Chinese users I'd like to ask to make sure there are
multiple channels to download the new Inkscape versions as bittorrents are
blocked by at least two ISP's here. Anything remotely social gets blocked
in this socialism the Chinese way state. I agree that the new release will
get quite some attention as it has been ages since the last major release
and Inkscape is well known as one of the FOSS must haves. In case of 0.91
it will also gets known very fast there are important perks such as the
greater speed of operation and a plethora of other improvements and new
tools. So we can expect a lot of downloads in the first two months and
then a gradual decrease in intensity. I do however expect an increase
overall as 0.91 is greatly more productive tool than 0.48 and Inkscape has
become more useful as a serious replacement for other tools.
For the roadmap I would like to ask how feasible it would be to add
javascript and SMIL to the renderer? There was a javascript plugin for
0.48 that I never managed to get to work. The instructions were in
Portugese, but the idea of being able to use javascript sure was a good
one. Add SMIL to it and you're all set for development of animation tools.
On the GUI side, I would like to ask how possible it would be to have the
GUI be constructed with SVG objects. That would allow enthusiasts to
radically revamp the GUI and make specialised versions with limited tool
sets for special tasks (think of Inkscape for kids) or change the GUI
depending on tasks at hand (animation GUI, cutter GUI, etc.). If the
Inkscape renderer would support javascript and SMIL it would open a whole
world of web designers to use their skills to create slick GUI's that
scale to whatever resolution in the future.
I personally use percentages in both SVG root and for objects. Currently
it means using Notepad++ to create groups to position things percentage
wise and changing sizes. The use case here is having a layout adopt to
whatever resolution of the user and display objects you want with scaling
backgrounds and positioning absolutely sized objects in the center of the
page. It would be great if Inkscape would support that natively and the
hassle of hand editing SVG code wouldn't be a necessity anymore.
I'm also quite exited by the idea that I won't have to contend with the
dumb 90dpi or 96dpi setting, but can use whatever setting is my fancy.
Having to work with 3.45xxx pixels per MM is really horrible. Setting that
to 10 and just use a viewport would make my life a lot easier. Considering
the new resolutions of screens for mobiles that go up 551 ppi these days,
having 90 or 96 dpi defaults with lots of decimals to position something
doesn't make much sense to me anyway. Having a higher dpi setting would
allow for working with whole numbers in files and might also increase
speed of rendering due to that I would imagine. Also nice for those
working with print btw.
My two cents,
Jelle
8 years, 6 months
clarification for new user faq re faking italics
by Brynn
Hi Friends,
We just need a couple of final clarifications for the new user faq. And fyi, I think we've decided to wait until after 0.91 comes out, to publish it on the live site. This is one, and the other will be in a separate message.
The old item "Bolding has no effect on some fonts" says:
Some fonts are available with in an unique, "normal" variant (i.e. no italics or bold). Nonetheless, Inkscape currently displays four styles available for them: Normal, Italics, Bold, Bold Italics. Italics is correctly faked by inclining the font but bolding cannot be faked at this point. Since the font itself does not have a Bold variant, the result would likely be of poor quality anyway. You should rather consider using a font with a real Bold variant.
When I re-wrote it, I wrote that italics can only be "faked" not "correctly faked" because in my experience, I have not been able to correctly fake an italicized font by skewing (which I assume is meant by "inclining"). (To me, italicized text doesn't just lean over, but sort of curves over.)
Can anyone speak to whether skewing is a correct italics or not?
Thank you very much!
8 years, 6 months
final clarifications for new user faq re SVG renderers
by Brynn
Hi Friends,
And there's a 3rd item to clarify, if someone has a chance. and
please note that these can all wait until after 0.91 is released!
The faq item "Inkscape and renderer X show my SVGs differently. What
to do?" mentions the Adobe SVG Plugin, which of course has been discontinued
a few years ago.
The text is below. Can "Adobe SVG plugin" just be deleted? If so,
does the rest of the item need to be rewritten? I do see this question from
time to time, in forums, so it's worth keeping the faq item. Just want to
have a correct answer :-)
"That depends on X. We accept Batik and Adobe SVG plugin as authoritative
SVG renderers because they are backed by some of the the authors of the SVG
standard and really care about compliance. This may not be true for other
renderers. So if you are having a problem with some renderer, please try the
same file with either Batik or Adobe, or better yet, with both (they are
free and cross-platform). If you still see a discrepancy with Inkscape
rendering, we want to look into it. Please submit a bug; don't forget to
attach a sample of the problem file to the bug report, and ideally include
screenshots too"
Thank you very much!
8 years, 6 months
clarification for new user faq re flowed text
by Brynn
Hi Friends,
Oh crap -- I just let that last message go without switching it to
plain text. REALLY SORRY!!
This is the 2nd clarification we need for the new user FAQ. The old
item re flowed text is shown below. It's the part about the SVG
specification that we think has probably changed. And we don't know exactly
what should be said.
I think Maren suggested Tav might be able to address this.
Thank you very much!
"When flowed text support was added to Inkscape, it was conformant to the
then-current unfinished draft of SVG 1.2 specification (and was always
described as an experimental feature). Unfortunately, in further SVG 1.2
drafts, the W3C decided to change the way this feature is specified.
Currently SVG 1.2 is still not finished, and as a result, very few SVG
renderers currently implement either the old or the new syntax of SVG 1.2
flowed text. So, technically, Inkscape SVG files that use flowed text are
not valid SVG 1.1, and usually cause problems (errors or just black boxes
with no text).
However, due to the utility of this much-requested feature, we decided to
leave it available to users. When the final SVG 1.2 specification is
published, we will change our flowed text implementation to be fully
conformant to it, and will provide a way to migrate the older flowed text
objects to the new format.
Until that is done, however, you should not use flowed text in documents
that you intend to use outside of Inkscape. Flowed text is created by
clicking and dragging in the Text tool, while simple click creates plain SVG
1.1 text; so, if you don't really need the flowing aspect, just use click to
position text cursor instead of dragging to create a frame. If however you
really need flowed text, you will have to convert it to regular (non-flowed)
text by the "Convert to text" command in the Text menu. This command fully
preserves the appearance and formatting of your flowed text but makes it
non-flowed and SVG 1.1-compliant. "
8 years, 6 months
Units update
by Tavmjong Bah
Hi,
It has been hard to keep track of everything going on with units in the
past couple of days. I've got some comments about what has been done and
where we should be headed. Please add your comments.
1. 'display_units'
I think we all agree that inkscape:document-units is meant to be
'display_units'. Johan's changing of 'doc_units' to 'display_units'
should make this much clearer. Thanks Johan!
(BTW, I change 'units' to 'page_size_units' last week for similar
reasons.)
2. 'svg_units'
I am not sure about what this actually means. The comment is:
// Units used for the values in SVG
Is this the suppose to be the unit identifier used inside the SVG file?
The only time that would be useful is if the 'user unit' has a real
world value of 1px otherwise unit identifiers don't mean what users
would expect them to.
Or is this the unit identifier in the root 'width'/'height'. In this
case, I think it might be useful to take a step back and look at the a
more global picture. The root SVG values of 'width' and 'height' along
with the 'viewBox' establishes the scale for the drawing. Typically one
has:
<svg width="20mm" height="20mm" viewBox="0 0 20 20" ...>
where the 'user unit' is equivalent to 1mm. But one could also have a
valid file with:
<svg width="20mm" height="20mm" viewBox="0 0 40 40" ...>
where the 'user unit' is equivalent to 0.5mm.
We really should support arbitrary scaling (including non-isotropic). So
instead of an 'svg unit' we should have an 'svg scale'. (Our rendering
already supports arbitrary scaling so it would be a shame if our GUI
didn't too, see the example SVG below.)
3. % values on root 'width' and 'height'
I saw something on IRC about % values on the root SVG 'width' and
'height'. This is actually a very common use case for web designers
where the SVG is to automatically fill a space. Inkscape treats % values
on the 'width' and 'height' by using the values from the 'viewBox' (or
if there is no 'viewBox' it assumes all values are in pixels). Here is
an example of where 'width' and 'height' are in % and the scaling is
non-isotropic. Inkscape renders it just fine:
http://tavmjong.free.fr/SVG/TEST_IMAGES/root_percent.svg
4. Precision
The SVG spec says that values like length are floats and this is indeed
what we use internally in Inkscape. I am wondering if we should change
this to double as it would make internal calculations more precise. This
might avoid some of the rounding errors when switching units back and
forth from say 'mm' to 'pc'.
We allow the user to set the numerical precision to up to 16 digits.
This makes little sense given that floats are good to only 6 or 7.
5. Converting between 90/96 dpi
I think our focus here is to do the minimum possible to convert an SVG
file between 90 and 96 dpi. Trying to scale everything inside the file
is rarely going to work satisfactory for a file of any complexity. Here
are some things we should try (I am brain storming here):
a. Add a 'viewBox'
If a file has been created to a specific size using only user units, say
A4 at 90dpi, using on user-units then one can set the SVG root to be:
<svg width="210mm" height="297mm" viewBox="0 0 744.09448819
1052.3622047" ...>
b. Absolute sizes are really only important for producing printed
matter. We could add a 'dpi' factor. Values must be converted in
PDF/PostScript export from 90 or 96dpi to 72dpi. The conversion factor
could be user selectable. (Although adding a 'viewBox' as above should
take care of this.)
c. Grids and guides and ?
These currently are defined in external units (no consideration of
transforms, viewBox, etc.). Guides should be easy to auto adjust using
the SVG scale (as defined above). Grids may be too (but I haven't tried
yet).
Note: We will need to update grids and guides when we do the coordinate
flip so if we do need a more sophisticated solution we can do it at the
same time.
d. Use internally of 'unit identifiers'.
If absolute unit identifiers ('mm', 'in', 'pt', etc.) have been used
internally (other than on the root SVG element), then these do need to
be scaled to account for a switch between 90dpi and 96dpi. This is not a
problem for pre-0.91 Inkscape created files. To keep it from being a
problem in 0.91 Inkscape files, we need to disable saving 'font-size'
with a 'pt' unit identifier.
Tav
8 years, 6 months
