New masthead
by Adam Pearson
bulia (I sent this to the user list in error!)
I think the site would benefit from more colour and a contrasting (i.e.,
serif) font as per attached; but I think others with greater graphic skills
than me are required!
Regards
Adam
----- Original Message -----
From: "bulia byak" <buliabyak@...400...>
To: <inkscape-devel@...6...>; "Inkscape users list"
<inkscape-user(a)lists.sourceforge.net>
Sent: Sunday, February 20, 2005 9:27 AM
Subject: [Inkscape-user] web site proposals
> I'd like to propose two things regarding the Inkscape web site.
> Volunteers are welcome:
>
> 1 Create an RSS feed for the main page news.
>
> 2 Create a new header graphic to replace the boring white "Inkscape"
> on blue. As a graphic app, we are starting to deserve something more
> sophisticated. The web site itself is OK, I don't think we need to
> drastically change the entire design (although suggestions are
> welcome), but the top panel is decidedly dull and pathetic. Show off
> your graphic talent! Send your submissions to the devel list for
> people to discuss. The best one (if the winner is not obvious, we may
> need to do a voting) will make it to the site. One technical note: the
> banner cannot be fixed width, because our site is not fixed width - so
> it must be either one piece for the top left corner or two pieces for
> two corners, with some flat color fill between them. The minimum
> screen resolution is 800x600.
>
>
18 years, 3 months
new SPRepr class names
by MenTaLguY
For reference:
SPRepr -> Inkscape::XML::Node
SPReprDoc -> Inkscape::XML::Document
SPReprAttr -> Inkscape::XML::AttributeRecord
SPReprAction -> Inkscape::XML::Event
SPReprEventVector -> Inkscape::XML::NodeEventVector
-mental
18 years, 3 months
SPRepr renamed! commits may resume!
by MenTaLguY
Okay, comitted the most evil of the changes (check out the 80-some line
ChangeLog entry XD). I'm not really done yet, but the remaining stuff
is much less likely to cause merge conflicts with anything anyone else
is working on.
-mental
18 years, 3 months
SPRepr renaming! hold off on commits!
by MenTaLguY
I'm getting ready to rename the SPRepr interface classes into the
Inkscape::XML namespace.
As I'll probably have to end up touching most of the files in the
codebase, it might be a good idea to hold off comitting anything until
I'm done.
Yes, I can resolve update conflicts before I commit, but they are more
likely to get resolved correctly if they happen on your end, since you
will understand your particular changes better, and you will
individually have fewer to handle than I would.
-mental
18 years, 3 months
New text layout engine design RFC
by Richard Hughes
See the attached header file for the first draft of what I think the
interface for the new text layout engine should look like. The
intended audience is developers, there's nothing to see here for
people who don't enjoy reading source code.
Comments are encouraged on design, comprehensibility, features, style
and smackdowns.
A few things to talk about, in no particular order:
1) Do we disapprove of public member variables, even where there's no
disadvantages to using them?
2) The coding style guide doesn't mention the how the names of
enumerations should be formatted.
3) I implement parse_svg_length_list() because the old flow_src did.
Should this really belong closer to the XML layer?
4) Likewise the xml:space attribute. The difficulty with moving this
is that you could cause roundtripping problems. Can we even do
roundtripping?
5) Lots of private members are missing still, because I don't know
what they're going to be yet.
6) The appearance of this document doesn't mean I've decided whether
to wrap the existing code, switch over the users, then write my own
innards, or to do it all in one big (destructive) commit. The latter
is quite a lot less work, but the former will likely be broken for
shorter intervals (although maybe more of them).
7..n) There are more things to discuss in the attachment, under the
heading "Comments", near the top.
That's it, I think. I'll remember something else as soon as I click
'send', of course.
Richard.
18 years, 3 months
.svgz reading
by unknown＠example.com
I just changed the gzip input stream to remove some of it's limitations. Please
give it a shake-down and see if it holds up. (It works on assorted-tiling.svgz
now)
18 years, 3 months
Fwd: Re: [cairo] cairo anti aliasing
by unknown＠example.com
----- Forwarded message from Samuel Abels <newsgroups@...722...>
-----
Date: Sat, 19 Feb 2005 01:19:37 +0100
From: Samuel Abels <newsgroups@...722...>
Reply-To: Samuel Abels <newsgroups@...722...>
Subject: Re: [cairo] cairo anti aliasing
To: Tim Janik <timj@...723...>
On Sat, 2005-02-19 at 00:38 +0100, Tim Janik wrote:
> i am seriously considering to use cairo as a rendering backend in
an
> anti-aliased canvas i'm currently working on.
In case you are using C++ - might we consider combining efforts?
http://cms.debain.org/
-Samuel
--
------------------------------------------------------
| Samuel Abels | http://www.debain.org |
| spam ad debain dod org | knipknap ad jabber dod org |
------------------------------------------------------
_______________________________________________
cairo mailing list
cairo@...278...
http://lists.freedesktop.org/mailman/listinfo/cairo
----- End forwarded message -----
18 years, 3 months
Adding CxxTest
by unknown＠example.com
I just did an initial checkin to add CxxTest.
http://cxxtest.sourceforge.net
Once you do an update, just run "make check" from the top level and you should
get src/libnr/testrunnr built and executed along with all the other tests.
Or to get just that one, change to inkscape/src and then run "make
libnr/testrunnr" to build it.
It runs CxxTest to create the needed .cpp from *-test.h files, then builds it.
18 years, 3 months
Fwd: Re: COMMENT: Flow Text
by unknown＠example.com
----- Forwarded message from Jon Ferraiolo <jon.ferraiolo@...720...>
-----
Date: Fri, 18 Feb 2005 09:51:22 -0800
From: Jon Ferraiolo <jon.ferraiolo@...720...>
Reply-To: Jon Ferraiolo <jon.ferraiolo@...720...>
Subject: Re: COMMENT: Flow Text
To: Thomas DeWeese <Thomas.DeWeese@...721...>, www-svg@...157...
Thomas,
Thanks for the great comments!
The SVG Working Group has given me the assignment of responding to
one of
our comments below. You said:
>4.14.2 The progression-align property
>
> Doesn't it make a _lot_ more sense to have this property
>apply to the flow regions? What does it mean to have a center
>aligned flowPara bracketed by two un-aligned flowPara elements?
>
> Also I think a description of how this is applied to content
>is in order. I can think of several "reasonable" interpretations
>which given 'odd' flow geometry could result in widely variable
>results.
The SVG WG believes the SVG 1.2 LC specification incorrectly defined
a
'progression-align' property when instead it is better to reuse the
'display-align' property from XSL-FO (defined within
http://www.w3.org/TR/xsl/slice7.html#area-alignment) , which
delivers
exactly what is needed. The next public draft of SVG will include
the
'display-align' property instead.
We agree that the 'display-align' property should apply to regions
and not
to flow content elements. The next public draft of SVG will say that
'display-align' applies to the text container object and not to
elements
that are part of the text flow such as <flowPara>.
In terms of the last paragraph about odd flow geometries and widely
variable results, I believe this issue only applies to
non-rectangular
regions. At the moment, the SVG WG is first addressing SVG Tiny 1.2
requirements (which only supports rectangular text regions) and is
adopting
the general policy proposed by others that flowing text layout must
allow
UA-specific layout algorithms to be deployed so that UA's are not
prevented
from delivering the best possible results. Although we haven't
resolved
your last paragraph completely yet, there is a possibility that we
will
allow layout variability in the general case (per the feedback of
others),
which might lead us to conclude that it is sufficient to simply
provide
layout guidelines for flowing text in arbitrary shapes (preserving
the
great technical work by the incredibly bright people who documented
the
existing algorithms - do you remember who contributed to that work?)
but
not *mandate* every possible detail for how layout is performed.
Jon
At 07:45 AM 11/8/2004, Thomas DeWeese wrote:
>Hi all,
>
> These are concrete problems/suggestions on the flowText
elements as
>currently specified (or underspecified).
>
>4.2 The flowRegion element
>
> "The children of a flowRegion element are inserted into
the
> rendering tree before the text is drawn and have the same
> rendering behavior as if they were children of a g
element."
>
> This is new and I don't think it's a particularly good idea. If
>people want the flowRegions to be rendered then there is the 'use'
>element. Given the above how are filters handled?
>
> "A flowRegion element has basic shapes and path elements
as
> children"
>
> I'm not a real Schema expert but it appears that it allows
>just about anything as a child (g, use, text, shapes). This is
>without comment on how these are combined to form the flow regions.
>Given that the desire here is almost identical to the clipPath
element
>(namely construct a set of geometry) I would strongly urge the WG
>to adopt the wording and methods used in clipPath (which restricts
>it's children pretty heavily).
>
> Given that the WG is likely not to take my advice ;) You need
to
>at least specify what having a 'g' means. Is all the geometry
>concatenated as one flow region? Are implementors expected to
'union'
>the fill regions of the children of the 'g'? Use if it is allowed
>to reference arbitrary content (which it isn't for clipPath) has
>similar issues.
>
> Also with text is all the text considered a single very complex
>flow region or is each individual letter a flow region? What about
>letters with multiple 'disjoint' pieces ('i',';','%')?
>
> All these comments apply equally to the flowRegionExclude
section.
>
>4.5 The flowPara element
>
> It needs to be clearly defined if 'block' here means CSS block.
>Also there are references to margin's elsewhere do they apply here?
>
> flowPara doesn't appear to allow flowLine as a child (in fact
>no one seems to allow flow line as a child).
>
>4.7 flowRegionBreak element
>
> It should be specified what the behavior is in the case that a
>flowRegionBreak element is empty or there are multiple together (as
>it is for flowLine). Also flowSpan doesn't allow flowRegionBreak
>element's as children, but flowLine and flowDiv do, is this
>intentional?
>
> Is flowRegionBreak more a flowPara or a flowSpan or something
>else (just a 'marker'?).
>
>4.13 Determining Strip Location
>
> How is line-height determined?
>
> What is the strip that is intersected with the geometry?
>
> If it is the line-height it is worth noting that this may be
>smaller than the content height meaning that text content may
>run into the flow geometry. If the content height (or line box)
>is used then this doubles the number of intersections needed to
>handle strip calculations (there are also other inefficiencies this
>introduces).
>
>4.14.2 The progression-align property
>
> Doesn't it make a _lot_ more sense to have this property
>apply to the flow regions? What does it mean to have a center
>aligned flowPara bracketed by two un-aligned flowPara elements?
>
> Also I think a description of how this is applied to content
>is in order. I can think of several "reasonable" interpretations
>which given 'odd' flow geometry could result in widely variable
>results.
>
>4.14.3 Overflow
>
> What is the processing model for this?
> Is this event generated before/after DOM mutation events?
> _Must_ it be issued for every mutation event that changes
>the state or may an implementation 'compress' overflow events
>as long as no rendering occurs between them?
>
> I would really like to lobby for allowing compression,
otherwise
>the layout must be performed on essentially _every_ modification of
>the content tree. I think UA's should be allowed to defer layout
>until just prior to rendering at which point if a flow has change
>overflow state events must be issued (which may change the flow and
>hence the overflow state, which may lead to new overflow events
before
>the rendering takes place, repeat as needed).
>
> This avoids the need to layout the text 12 times because 12
>properties were changed in the flowText tree (even when none of
>the 12 actually causes an overflow event).
>
> For async renderers (that don't normally hold up rendering
until
>'script' completes) they would only be required to dispatch the
event
>before 'unsuspendRedraw/All' and 'forceRedraw' complete.
>
>4.15 Example
>
> Aside from the already noted 'well formedness' problem
("</flow>"
>instead of "</flowRoot>"). The namespace declaration is wrong
>(you want "xmlns=" not "xmlns:svg="). Also in the first example
>the flowRegion appears to be a parallelogram instead of the
>desired trapezoid (I think the last L should be L200,50 - although
>even that goes 'outside' the stroked trapezoid on the bottom).
>You might be better off using margins here and referencing the
>stroked trapezoid.
>
>Other Properties:
>
> There should really be a consideration of other properties
>implementations need to be mindful of from CSS. A few that
>come to mind: 'margin', 'margin-*', 'text-indent'?, 'white-space'?,
>'line-height'. Without this it is unclear what an implementation
>is expected to support.
>
>
----- End forwarded message -----
18 years, 3 months
Saving as pov
by Lucas Vieites
Hi,
I've been trying to render the exported pov files from simple svg
images but I keep getting errors.
I'm using povray 3.6 to render the attached pov file, generated from
the attached svg file.
I'm also attaching the output ;-)
Thanks for your help,
--
Lucas Vieites Fariña
Dept. Desarrollo <lucas@...212...>
Asix Informática <http://www.asixinformatica.com/>
Tel/Fax: +34 986 54 26 98
18 years, 3 months
