User:Pajarico

Notes

Command to revert to an older SVN revision:

svn update -r 19664

Interesting projects by other people

LazyNezumi

Kinematic Templates, 2

Patterns in Illustrator

What grinds my gears (small annoying bugs)

Filters

When a filter is added, tweaking the blur form the F&S dialog will deactivate the current filter and substitute it for the blur primitive.

Expected: blur should be added to the other filter.

Workaround: group the object and then apply blur.

Spiro splines

Editing Spiro splines could be improved.

• The red path is not the same as the real Spiro path. I guess it can be misleading for new users and certainly sometimes it gets on the way.

• Yes it's possible to disable it, but then I don't see the path and thus I cannot place new nodes (see next).

• Nodes cannot be added clicking on the spiro path.
• The icons for the nodes shown on canvas could be changed to differentiate them from the nodes on a typical bezier path. Only two icons would be needed (round and corner nodes).
• Many of the options on the toolbar do not apply for spiros:

• Basically, I would reduce all the options to smooth nodes and corner nodes. The rest are only really relevant for bezier, Spiro users don't benefit from them.
• Right now, to get a corner you have to click twice on the corner node button (once for switching current node to a corner node, twice to retract handles). One click should be enough.

Color stuff

Jon Cruz's Auto swatches

• Can't use an auto swatch as a gradient stop.
• When transformed with the selector tool, Auto palette stops reflecting if the object is using one of the swatches.
• No clear differentiation between usage of swatches in fill and stroke.

Fill&Stroke dialog issues

• It is used for three things,

• Object propierties (tabs Fill, Stroke and Stroke style).
• Gradient stops editing.
• Swatches editing.

...which results in misleading behaviour and an excess of UI elements (for instance, a gradient stop just have a color and alpha and it doesn't need two color tabs -Fill and Stroke- and a third one with nonsensical options -Stroke style-).

Blueprints

Blueprint template

User oriented debug and report

Informative UI (hyperlink-like shortcuts on UI)

Right now the status bar has information displayed as this:

• Path (21 nodes, path effect: Spiro spline); filtered (Evanescence), in layer color. [Rest cut for this example]

In other words:

• Type of object (N nodes, path effect: name_of_path_effect); filtered (name_of_filter), in layer name_of_layer.

I think that key words of the text can be converted to hyperlink-like shortcuts, like this:

• Type of object (N nodes, path effect: name_of_path_effect); filtered (name_of_filter), in layer name_of_layer.

• path effect: name_of_path_effect: This shortcuts to the LPE editor dialog.

• filtered (name_of_filter): This shortcuts to the filter editor dialog.

Additionally, name_of_layer could be converted to a keyword too that shortcuts to the layer dialog with that layer selected. I haven't included it because personally I use the layer dialog less and prefer calling it from the toolbar.

This idea could be extended to other parts of the UI, for example for linking to tutorials from some dialogs like the primitives of the filter editor. Info boxes are OK but a bit too obscure; having a Read more... link to a tutorial would help. Tooltips could have a link to specific tutorials too. Extensions could have hyperlinks to author webpage or to a tutorial explaining the parameters.

Advantages:

1. Basic appearance properties are already there (fill, stroke, stroke width, opacity) and double clicking them opens the Fill&Stroke dialog. Adding ways of accessing filter and LPE editing dialogs seems like a reasonable step to me (because both of them affect the appearance of objects).
2. The shortcuts are painted with another color, making detection of an added filter/LPE easier with just a glance at the statusbar.
3. Direct access to two of the most used dialogs (IMHO) from the main UI without having to use the menus.
4. It doesn't take more space than the current solution so it won't affect negatively narrow screens.

Disadvantages:

1. Might not be doable in GTK+ (unsure).

Better markers edition

Markers have several propierties (see SVG reference) that should be exposed to the user:

• Size (markerWidth, markerHeight).
• Rotation (orient).
• Offset from the normal position (refX, refY).
• Transformations relative to... (markerUnits):

• ...to stroke width (strokeWidth).
• ...to object's coordinates (userSpaceOnUse). [I'm unsure about this. I understand that the size will be relative to the object used as a marker and thus stroke size won't affect it, right? So size could be set separately from the stroke this way, correct?]

• Colour: Inherit from stroke or user selected (see bug [1]).

An additional button to edit this directly on canvas (per marker) would be an excellent companion.

Better linestyle edition

Right now, is not possible to edit linestyles unless you use the XML editor:

• Not easily discoverable for new users.
• Not easy to use.
• The update is not immediate and the user has to fiddle a lot with values to get the expected design.

I propose adding some text input boxes to the Stroke style tab were the user can input several values like this:

|box 1|box 2|box 3| box 4|box 5|

So odd numbers add a stroke of that lenght, while even boxes add a space of that lenght.

I think 5 boxes would be enough to get complex patterns, but more boxes could be added if needed (the reference doesn't seem to have a limit about this).

[DONE] Tweak tool addition

A mode that changes the size, rotation and distribution of objects (think of a broom pushing objects).

Spray tool

Adds sprayed motives to the canvas. The "motives" could be a basic circle, more complex ones or objects on clipboard. When sprayed the motives sum up like when you paint with a real spray can. I guess it would be better to have a switch for letting the result be made of individual objects or only a path. Painting with a selected object would alter the original path adding the sprayed motive (similar to the Tweak tool workflow).

Settings:

• Density of the sprayed motives (number of motives sprayed). A subswitch to alter density automatically depending on lightness/opacity of the background image.
• Size of the "brush".
• Random size variations.
• Color tweak (like tweak tool, but with direct access instead of having to do it afterwards).
• Ideally, many more. similar to a bitmap-editing app, with many settings for the dynamics of the "brush".

Another possible switch (lower priority/harder to code):

• The paint pours from dense zones (areas where in a click and hold action get too many "paint").

Drop Shadow LPE

http://www.youtube.com/watch?v=OU_dLSpAdqQ&NR=1

Bevel/Extrusion/Emboss LPE

Bevel/Extrusion/Emboss on CorelDraw X3: http://www.youtube.com/watch?v=OzlaE4IJzr8

I would strongly appreciate any thought about this and how it feels and looks in other apps.

Tesselation LPE

http://en.wikipedia.org/wiki/Tessellation#Tessellations_and_computer_graphics

http://euler.slu.edu/escher/index.php/Introduction_to_Tessellations

http://www.cgl.uwaterloo.ca/~csk/projects/escherization/

http://members.tripod.com/vismath6/fath/

Lens LPE

Synfig lens: http://www.youtube.com/watch?v=GAWtndOHkUw&feature=related

Some ideas:

• The helper of this LPE should be a circumference which is the effect area.
• The lenses can be concave or convex, meaning a different deformation happens.
• The user controls:
  • Well, I actually need more knowledge on this to write about real-life parameters to be presented to the users. Don't need to be exhaustive or too realistic, these parameters are to be orientative.
• I've tried to see if this effect is achievable by using the envelope LPE and I think it is not. At least I can't perform myself an editing of the sides which looks circular/spherical enough.

Sketch

Improve it by adding the sketch effect to the fill instead of only to the stroke.

Revision Control

http://en.wikipedia.org/wiki/Version_control

This might benefit from the implementation of a code revision control since SVG are text files. The idea is to link this with a Site uploading feature (do editions form inkscape of files on a web server without having to upload the whole file, like web IDEs).

Extensions Repository

Ideas:

• Searchable content based on tags, categories, descriptions, name, etc.
• Downloadable content ready to use.
• See description and screenshot before downloading.
• Allow the user to uninstall/disable extensions safely. (NOTE: even in the current paradigm where extensions are just like scripts, disabling could have a benefit side allowing the user to decide which extensions are shown in the menu, meaning less crowded menus).

Concerns:

• Security issues when dealing with external files/apps.
• Trusting of the extension/author.
• Current extensions are not sandboxed.
• Portability on scenarios where the architecture may play a role.

Current extensions in SVN

ExtensionArchitectureProposals

ExtensionsSystem

<Pajarico> I was thinking about a repository and a UI for searching for plugins
<Pajarico> Like firefox3 one
<^-> [JonCruz] KatteKrab: :-)
* KatteKrab (n=kattekra@caffeine.cc.com.au) has left #inkscape
<^-> [JonCruz] EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEK!!!!!
<^-> [kattekrab] uhoh!
<^-> [JonCruz] Pajarico: sorry. Just had my CISSP hat on for a second there
<^-> [JonCruz] :-)
<^-> [JonCruz] pjrm: re the mail.... quick!!! Do a Jean-Luc Picard impersonation
<^-> [pjrm] We already have a repository for inkscape plugins: https://inkscape.svn.sourceforge.net/svnroot/inkscape/inkscape/trunk/share/extensions
<Pajarico> JonCruz, I don't get it
<^-> [JonCruz] Pajarico: well... it's a bit of a security risk
<^-> [JonCruz] Pajarico: but I think that's a minor factor here.
<Pajarico> But isn't the same scenario than firefox3?
<^-> [pjrm] Pajarico: The issue is that plugins aren't currently sandboxed
<^-> [pjrm] I don't know the arrangements for firefox plugins, but i do know that whatever the arrangements are, plugins are considered a major part of the security risk of using firefox.
<^-> [JonCruz] Pajarico: somewhat similar
<Pajarico> pjrm: short answer: then they should be sandboxed ;)
<^-> [pjrm] Yes, that would be good
<Pajarico> I had troubles myself with some firefox plugins
<Pajarico> the point of an official repository would be to reduce those risks or borking your inkscape installation
<Pajarico> by ratings comments and some testing done before the publication of each plugin
<^-> [JonCruz] Pajarico: and digital signatures
<^-> [JonCruz] :)
<Pajarico> sure
<Pajarico> good call
<wormsxulla> digital signatures?
<wormsxulla> nah nah nah
<^-> *** JonCruz smacks wormsxulla upside the head with his CISSP cert
<Pajarico> wormsxulla, what's the problem?
<wormsxulla> no extension developers can afford digital signatures, that's why the extensions are on AMO/https and have to be reviewed and stuff
<^-> [JonCruz] rpms and debs can be signed
<Pajarico> well, aside the technical dilemmas in this, my idea was more broader
<wormsxulla> but you can"t do that at no charge for windows, can you?
<^-> [JonCruz] I can... but not for Microsoft
<Pajarico> the UI inside inkscape should allow to see a description and the installation of the plugin
<Pajarico> in an easy way
<^-> [JonCruz] it's all a matter of trust roots
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] Pajarico: cross-platform is probably the bigger issue
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
<Pajarico> JonCruz, maybe, but I can't comment on that since I'm running Linux
<^-> [JonCruz] the good news is that most people don't use Inkscape for online commerce
<Pajarico> and plugins kind of "just work" most of the time
<^-> [pjrm] not just a matter of trust roots; rather, we have good reason to trust that most plugin authors don't give much attention to security issues.
<^-> [pjrm] So sandboxing is more important that signatures.
<^-> [pjrm] s/that/than/
<^-> [JonCruz] very true
<wormsxulla> JonCruz: i saw a "template" for inkscape recently (to design and sell furniture)
<^-> [JonCruz] general risk assessment agrees with pjrm
<BackCat> anyway
<BackCat> is SVG standard support 'blend'?
<Pajarico> well, in Linux I just have to copy the file to a folder, so what's the problem for cross-platform'ing?
<BackCat> and will inkscape support blend in future?
<^-> [pjrm] BackCat: svg 1.2 has some compositing operators, if that's what you mean.
<^-> [pjrm] svg 1.1 has only alpha blending
<BackCat> ic
<^-> [JonCruz] BackCat: http://www.w3.org/Graphics/SVG/Test/20061213/htmlObjectHarness/full-filters-blend-01-b.html
<^-> [pjrm] (with minor variations such as choice of colour space, gamma stuff, and the like)
<BackCat> i wonder if inkscape can done the same 'blend' as illustrator or corel draw
<^-> [JonCruz] Pajarico: what is a plugin? A script? Perl? Python? Bash? Java? C++? C#? etc.
<^-> [pjrm] i don't know what you mean by "blend"; I'd have thought that blend would either mean simple alpha compositing, or would mean something other than compositing.
<Pajarico> JonCruz, sorry I'm going to answer your question with another question
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<Pajarico> what are polugins rigth now in inkscape
<Pajarico> ??
<BackCat> no, i didn't meant alpha compositing, since i've got gimp in that topic
<BackCat> wait, gues i have to search some sample
<Pajarico> The one I've been using are inx files
<Pajarico> and i was basically thinking about those
<^-> [JonCruz] BackCat: just start clicking on next and see what other things are in SVG 1.1
<wormsxulla> http://www.ponoko.com/make-and-sell/downloads#templates
<BackCat> ok
<BackCat> actually, i wished i could done something like:
<BackCat> http://www.bittbox.com/illustrator/fun-with-illustrators-blend-tool/
<BackCat> which could be done in illustrator
<^-> [JonCruz] Pajarico: .inx files just describe an extension. The extension itself can be in just about any language. So many will be portable, but some may need to be compiled for the architecture
<^-> [JonCruz] BackCat: effects and misc plugins are your friends
<Pajarico> JonCruz, what about inx+py? those should be portable?
<BackCat> any refference to such plugins?
<BackCat> i use standard installation for inkscape, which comes with my distro
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<^-> [JonCruz] http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Effects-GenerateFromPath.html#Effects-Interpolate
<^-> [JonCruz] Pajarico: probably
<^-> [JonCruz] BackCat: http://tavmjong.free.fr/INKSCAPE/MANUAL_v14Draft/html/Paths-LivePathEffects.html
* markyt (n=mark@c-71-198-186-93.hsd1.ca.comcast.net) has joined #inkscape
<^-> [JonCruz] BackCat: the Live Path Effects are newer and can do some interesting things... and most importantly can be adjusted later
* BackCat on the go, thx :)
<BackCat> that's what i meant by help :D
<Pajarico> Also my idea was to have a extensions manager where you could install, uninstall or disable any plugin
<Pajarico> should i start a blueprint?
<^-> [pjrm] "disable" a plugin ?
<^-> [JonCruz] Pajarico: Sure... but look into what aspects might overlap the OpenClipArt browser/import/export
<^-> [pjrm] I thought that the only sense in which plugins were "enabled" / "disabled" is whether they show up in menus or not?
* pierremarc has quit (Read error: 113 (No route to host))
<Pajarico> pjrm, i'm sorry, i guess i was thinking about Indesign, Illustrator et alia
<^-> [pjrm] oh, though i suppose import filters are slightly different
<Pajarico> but in a broader way, plugins could be something that adds new tools, buttons, nad features
<^-> [JonCruz] pjrm: have you used Eclipse?
<^-> [pjrm] no, actually, i haven't.
<Pajarico> the problem is that current inkscape way of handling this issue is as a sort of automated scripts
<^-> [JonCruz] Ahh... it deals with this general issue... but poorly IMHO
<wormsxulla> (if you have a plugin manager, doesn't that mean that plugins have to all be designed with "special" features that make them "enable-able", "install-able" and stuff?)
<Pajarico> JonCruz, please elaborate, you mean Adobe?
<Pajarico> wormsxulla, really? how so?
<^-> [JonCruz] Pajarico: Eclipse
<wormsxulla> Pajarico: i think so, just asking to verify :)
<Pajarico> well i don't see how
<^-> [JonCruz] wormsxulla: or the sandbox could deal with that
<Pajarico> i'm not programmer BTW
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("time for some fun with inkscape, open source matter :D")
<Pajarico> to which extent are current extensions not sandboxed?
<^-> [JonCruz] wormsxulla: ted has a good start with the existing .inx descriptor files
<^-> [pjrm] If "disable" means "pretend that it isn't installed", then it probably doesn't require special feature of the plugin to handle enabling.
<wormsxulla> JonCruz: hmmmmmm
<Pajarico> I mean may i write a python extension that deletes files?
<^-> [pjrm] Pjarico: yes
<^-> [JonCruz] Pajarico: yes. And you may write one that formats the hard drive. Although we strongly recommend against that
<^-> [pjrm] in fact, lots of extensions do delete files.
<^-> [pjrm] Probably not "formats the hard drive", given that that's usually protected by the operating system.
<^-> [JonCruz] at the moment they are just executed as stand-alone programs of whatever type they run
<^-> [JonCruz] pjrm: only real operating systems. Remember we have more users on Windows.  :-)
<wormsxulla> tsk tsk tsk ;)
<wormsxulla> "we have more real users on non-real OSs" :)
<^-> [pjrm] (Re "lots of extensions do delete files": Specifically, lots of extensions create a temporary file or two, and clean it/them up afterwards.)
<Pajarico> so is sandboxing a reasonable goal in the mid-term?
<^-> [pjrm] The implication of "lots of extensions create temporary files" is that unfortunately extensions do want access to the file system, which makes it harder to sandbox them.
<^-> [pjrm] Similarly, lots of extensions want to be able to execute other programs.
<^-> [JonCruz] pjrm: you forgot to do your picard impression
<^-> [pjrm] So it's hard to allow running dia, but not allow running rm -rf.
<Pajarico> and is it reasonable to let the files be exposed to dubious extensions?
<^-> [pjrm] JonCruz: Actually, i didn't get the reference, sorry.
<^-> [JonCruz] pjrm: http://en.wikipedia.org/wiki/Jean-Luc_Picard
<^-> [pjrm] i recognize the name, but didn't understand the applicability to the situation
<^-> [JonCruz] pjrm: his signature phrase
<^-> [pjrm] OTOH, many extensions don't require access to filesystem or external programs.
<^-> [pjrm] Maybe we can use a sandbox for those extensions, and more expensive auditing etc. for the others.
<^-> [pjrm] JonCruz: "make it so" ?
<Pajarico> can something be sandboxed and still call an external app?
<^-> [JonCruz] pjrm: ok. will do!
<^-> [pjrm] Pajarico: not very usefully.
<^-> [pjrm] maybe i exaggerate.
<^-> [JonCruz] pjrm: that actually is a factor in support of running through ishmal's java script engine. Easy to add a security manager to that
<^-> [pjrm] The problem is that calling external apps often allows running arbitrary code.
<Pajarico> pjrm, remmeber i'm not a programmer so don't bash me :P. I thought it was possible to make a verb that calls another app safely
<Pajarico> maybe I'm being naive
<^-> [pjrm] Rephrased: Any extension that runs an external app needs auditing, but OTOH it may still be useful to sandbox that extension as well.
<^-> * kattekrab has left
<Pajarico> something like function_call_DIA(parameters)
* dneary (n=dneary@mne69-9-88-163-116-163.fbx.proxad.net) has joined #inkscape
<Pajarico> so the author of the extension doesn't call DIA directly
<^-> [pjrm] Yes, i did think of that, and was trying to phrase it in such a way that that would be considered inkscape running the external app.
<^-> [pjrm] The call_dia verb would need auditing.
<Pajarico> but not the extension using it
<^-> [pjrm] well, that depends on the call_dia verb, and what its audit reveals.
<Pajarico> pjrm, but what i mean is that the call_dia is a part of the sandboxed setup inside inkscape
<^-> [pjrm] Some operating systems provide things that might be considered sandboxing facilities.
<Pajarico> so it is safe to call dia
<Pajarico> BTW, are there any extensions that are NOT written in python?
<^-> [pjrm] I believe i've seen perl and shell script in use.
<^-> [JonCruz] yes
* mugdha has quit (Read error: 113 (No route to host))
<Pajarico> but anything that needs compiling?
<^-> [JonCruz] some... here and there
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
* JucaBlues (n=felipe@189.79.66.116) has joined #inkscape
<^-> [pjrm] oh, and one ruby script.
<Pajarico> I need to know if this conversation grants the effort to do a blueprint or if it is a plain no-no on your side
<^-> [pjrm] JonCruz: namely?
* pierremarc (n=pierre@ALyon-152-1-16-238.w83-197.abo.wanadoo.fr) has joined #inkscape
<^-> [JonCruz] not sure if any are in SVN, but I'd seen some in the past
<^-> [pjrm] Pajarico: Probably the most useful part of an extension manager would be some way of finding useful plugins from the set of plugins distributed with inkscape.
<^-> [pjrm] As previously noted, enabling/disabling isn't particularly useful for what inkscape plugins can currently do.
<Pajarico> pjrm, i disagree now
<^-> [pjrm] re enabling/disabling, you mean?
<Pajarico> disabling has the advantage of managing your extensions and let show only the ones you care about
<Pajarico> so is not as much as disabling/enabling raher than see/hide
<^-> [pjrm] Could that be done by showing recently-used plugins at the top of the list, followed by a separator, followed by all plugins?
<^-> [pjrm] Just so that there's no explicit action needed to show/hide
<Pajarico> pjrm, thing is i don't quite like the "recently used" solution
<Pajarico> i was thinking in something more tidy, in submenues even
<Pajarico> so one can arrange the extensions he needs for a continuous use
<^-> [pjrm] I'm not an artist; can someone else comment?
* JucaBlues (n=felipe@189.79.66.116) has left #inkscape
<cleary> I find the kb shortcut for frequently used menu items gets drilled quickly into my workflow
<Pajarico> there is already a last used shortcut in the Effects menu, and i use it too
<Pajarico> but many times i end looking on the submenus after my extension which is a bit cumbersome when you deal with many
<Pajarico> most of the time I'm using just like 5 extensions at most
<Pajarico> and the rest i don't care
<Pajarico> for what i see you have smashed or my illusions ;)
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* yeassay (n=larry@AGrenoble-257-1-119-209.w90-27.abo.wanadoo.fr) has joined #inkscape
* AndyFitz has quit (Read error: 54 (Connection reset by peer))
<yeassay> h
<yeassay> i
<Pajarico> let's talk about colors then
<Pajarico> does inkscape has recently used colors list?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* BackCat (n=webmaste@125.160.45.94) has joined #inkscape
<^-> [JonCruz] hmmm... what is a color
<^-> [JonCruz] ?
<^-> [JonCruz] perhaps a "swatch" is more appropriate?
<Pajarico> JonCruz, your metaphisycal questions kill me ;)
<Pajarico> a color is (to me) the RGB triplet that you assign to the stroke or fill of an object
<^-> [JonCruz] :-D
<^-> [JonCruz] good. Then I'm doing my job
<^-> [JonCruz] Feh! triplets suck
<BackCat> hahahahaha
<^-> [JonCruz] http://codewideopen.blogspot.com/2008/03/what-is-swatch.html
<Pajarico> JonCruz, i read that some days ago
<Pajarico> what we have now
<Pajarico> you open a palette and you have the colored swatches right?
<Pajarico> that's what i mean
* BackCat (n=webmaste@125.160.45.94) has left #inkscape ("later")
<^-> [JonCruz] well... we probably want styled/named colors
<Pajarico> or the colors you assign to an object or you edit on the Fill&Stroke dialog
<^-> [JonCruz] so you can reuse them. And change them
* eboyjr (n=eboyjr@ip68-104-8-96.lv.lv.cox.net) has joined #inkscape
<Pajarico> JonCruz, i agree named colors is the way to go, absolutely
<eboyjr> Is there a reason that inkscape's layout is like print preview?
<^-> [JonCruz] internally those could be   fill:#ff00ff
<Pajarico> but i was looking for a list of recently used colors
<^-> [JonCruz] or fill:url(#myMagenta)
<Pajarico> instead of just colors it should show colors and gradients too
* Plaidrab has quit (Remote closed the connection)
<^-> [JonCruz] or they could be *really* fancy colors    http://create.freedesktop.org/wiki/index.php/Swatches_-_colour_file_format/Propositions#Proposition_H
* kaeso (n=luca@debian/developer/kaeso) has joined #inkscape
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<Pajarico> uhmm, any thoughts?
* AndyFitz (n=AndyFitz@202.95.86.146) has joined #inkscape
* bryce_ has quit ("http://bryceharrington.org/drupal/")
<^-> [pjrm] Eeek, i've just noticed the clock; time to go.  As for installing random plugins from the net, this depends on how quickly we can provide sandboxing, and how useful that sandboxing is.  A starting point is to find an interpreter that has a suitable sandboxing option, even if that means forbidding executing external programs.  XSLT is a good example of such an interpreter/language; we ought then to look at our chosen
<^-> [pjrm] xslt interpreter to see if its source code contains any calls to system, popen, exec etc.auditing is mostly a matter of though we'd need to look at our chosen interpreter to see if it ever runs external
* AndyFitz has quit (Read error: 104 (Connection reset by peer))
<^-> [pjrm] s/etc.*/etc./
<^-> * pjrm has left: Disconnected