Board index FlightGear Development Canvas

SVG editing skills needed

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

SVG editing skills needed

Postby zakalawe » Sat Jan 18, 2014 11:19 am

Looking for an SVG volunteer with more Inkscape skills than me (I.e, practically anyone), to make a copy of Gijs' PFD.svg with about 50% of the elements removed and the rest updated to look like:

Image
Image

Especially, making the clipping path for the horizon element is too much for my path editing skills, and getting the roll-angle tick marks to line up correctly. The entire altitude tape can be removed, and the speed-tape is much simpler. Removing the compass and updating the AP command mode elements I can probably manage myself.

If someone can help me with the SVG, I'll adapt the .nas side and then we can have Canvas in the 737-Classic and 757, both of which would really benefit from it. (Note there are tends, if not hundreds of variants in the exact appearance of this instrument - ones with a speed tape and without, with an altitude tape and without, and more besides - the one on the b737 site is pretty common and 'useful')

I wish I could edit the SVG myself, but I really find Inkscape terrible to use - and I lack the patience to calculate the clipping paths by hand.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: SVG editing skills needed

Postby Hooray » Sat Jan 18, 2014 5:14 pm

zakalawe wrote in Sat Jan 18, 2014 11:19 am:I'll adapt the .nas side and then we can have Canvas in the 737-Classic and 757, both of which would really benefit from it. (Note there are tends, if not hundreds of variants in the exact appearance of this instrument - ones with a speed tape and without, with an altitude tape and without, and more besides - the one on the b737 site is pretty common and 'useful')


What exactly are your Nasal/coding plans related to Gijs' PFD code ? I am asking because I mentioned a couple of times that I was hoping to look into it as some point, specifically with the intention to make things as portable and as flexible as the ND framework - i.e. to support at least multiple independent instances per aircraft, but also support different types of aircraft (beyond just Boeing and Airbus). Obviously, this requires a fair deal of generalizing things and getting rid of hard-coded assumptions. The other use-case that the ND code now supports is easily rendering these instruments in GUI dialogs, no matter if these are PUI widgets or "native" Canvas windows.
Basically, my idea was to generalize the ND code some more and come up with helper classes for 1) SGSubsystems, 2) MFD instruments and 3) image generators, 4) displays and display switches/selectors. Introducing a handful of helper classes would allow us to support all important use-cases that are common in modern glass cockpits, including switching between different FMCs or PFDs/NDs.

Overall, removing SVG elements to come up with custom SVG files is not such a good idea - the approach taken by the ND module is to have a common/shared SVG file for different types of NDs, with added symbols for different types of aircraft - these are loaded into canvas groups, i.e. can be trivially animated, but also shown/hidden. The long term idea here being to encourage developers to maintain a single SVG file that lives within $FG_ROOT, rather than within $FG_AIRCRAFT - so that we can grow a library of symbols and different "styles" (themes) - for different types of aircraft and glass cockpit systems.

This approach is also favored by Gijs and Hyde.

In general, we really don't want to see a ton of custom files for different aircraft, no matter if this is a ton of Nasal spaghetti code, or custom SVG files - these PFDs are similar enough to be driven by a common generic back-end, using symbols from a single SVG file with different groups/layers. The way the ND code has been reworked, makes it possible to factor out custom stuff into helper hashes, which animate a single element independently - this can be triggered via listeners, timers - or permanently run via polling in a single update() loop.

Generalizing Gijs' PFD code accordingly would probably take 2-3 weekends, integrating and unifying this with the ND "framework" would be another 2-3 weekends.
I would really prefer to closely coordinate things here - we really don't want to have people come up with hugely different approaches for different types of MFDs.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby TheTom » Sat Jan 18, 2014 6:44 pm

The horzizon looks like a mirrored version of the C-130J horizon:
Image

The canvas only supports rectangular clipping regions (glScissor) so you need to fill the remainging parts of the rectangle with a background colored shape (in your case just two segments of a circle).

Here is the according SVG: https://www.dropbox.com/s/3ekmpfh0qgf2cka/PFD.svg Creating the horizon clipping and bank marks would take maybe 10 minutes for me.

I'm not sure if it is really a good solution to use a single svg files with all possible PFD elements and combine them (from Nasal?). We could to a collection of elements and copy them together, but there are so many different types of layouts that it will not be possible to cover every possible visualization. Also positioning and resizing the elements is much easier and faster from within InkScape. A common framework in the background (with some common elements like "rotating" numbers, HSI logic, trend vector calculations, etc.) is definitely a good idea.
TheTom
 
Posts: 322
Joined: Sun Oct 09, 2011 11:20 am

Re: SVG editing skills needed

Postby Hooray » Sat Jan 18, 2014 6:54 pm

When we came up with the idea of sharing a common SVG file, this was primarily about the Boeing series of airliners (747, 747, 777, 757 etc) - the point being that we want to avoid unnecessary duplication of functionality - if we introduce separation too early, things are likely to be adopted in a "copy & paste" fashion probably - that's in fact how Hyde started adapting Gijs' 747 ND for use in the 777, and neither Gijs or myself were really thrilled about it.
As a compromise, I would suggest to maintain manufacturer specifics SVG files instead - i.e. either based on aircraft manufacturers (Boeing/Airbus) or based on EFIS manufacturers like Honeywell.
Overall, I would just suggest not to separate things too early - or people are going to end up using lots of "copy & paste" to implement certain features.
FG development isn't overly organized - so we basically need to "force" people to generalize things by adopting a corresponding framework that encourages generalization at its core.
But I can perfectly understand that the C130J would not be well served by a Boeing or Airbus-based SVG file... so better grow a "library" of symbols for different manufacturers, but ensure that this does NOT live within $FG_AIRCRAFT
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby zakalawe » Sat Jan 18, 2014 7:24 pm

TheTom wrote in Sat Jan 18, 2014 6:44 pm:The canvas only supports rectangular clipping regions (glScissor) so you need to fill the remainging parts of the rectangle with a background colored shape (in your case just two segments of a circle).

Here is the according SVG: https://www.dropbox.com/s/3ekmpfh0qgf2cka/PFD.svg Creating the horizon clipping and bank marks would take maybe 10 minutes for me.


I spent considerably longer than ten minutes and didn't produce anything I was happy with at all - are you doing anything special in your Inkscape workflow? I found everything very imprecise to produce elements as structurally well-defined as the symbols for the EADI. (I.e I can see how Inkscape works for freehand splines, but I can't make anything 'accurate' using it)

In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND).

Maybe you could make a system where symbols can be grouped arbitrarily in SVG files, and layered together? Eg one layer for the speed-tape, one for the altitude-tape, one for the horizon. (Does Inkscape support including a layer from another SVG file?). Since I agree being able to position elements visually is very nice.

Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself :D
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: SVG editing skills needed

Postby Hooray » Sat Jan 18, 2014 7:25 pm

Maybe you could make a system where symbols can be grouped arbitrarily in SVG files, and layered together? Eg one layer for the speed-tape, one for the altitude-tape, one for the horizon.

This is basically how the ND code currently works: each SVG element is loaded into a separate sub-group, that can be individually controlled and animated - see Gijs' SVG file to learn how it work.
The Nasal code has been significantly inflated during the last few weeks, but it's basically still the same concept.

zakalawe wrote in Sat Jan 18, 2014 7:24 pm:Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself :D

So what exactly are you going to do with Gijs' code then ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby Philosopher » Sat Jan 18, 2014 11:58 pm

zakalawe wrote in Sat Jan 18, 2014 7:24 pm:I spent considerably longer than ten minutes and didn't produce anything I was happy with at all

Haha, our excellent C++ dev is stumped! Are you using the little red-on-hover handles to manipulate the curvature? Using the F2 tool & clicking the object (or double-clicking with F1) and clicking on a close-by node/path segment reveals those, and I find they give me adequate control over the curving. Double-click on the path to insert a new node for more precision... Or you could insert an oval, turn it into a path ("object" menu IIRC), take out some of the sides, add a few points to make an inversion of sorts (i.e. until it meets up with the clipping rectangle), and fill it in with black...

zakalawe wrote in Sat Jan 18, 2014 7:24 pm:Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself :D

Yes, Gijs & Hooray & I are working on that (now that I'm back). It's a combination of Nasal/canvas/map.nas, canvas/MapStructure.nas, canvas/map/navdisplay.mfd, canvas/map/* (*.draw, *.layer, *.model - OLD; *.scontroller, *.lcontroller, *.symbol - NEW), and one aircraft-specific file which I haven't had to touch.

As Hooray said, it still needs work and clean up, which is my plan (soon). Ideally we'll be moving to the new MapStructure framework more and more (though incrementally!), getting rid of hacks and "spaghetti code", and then ensuring everything works right. Adding new symbols, etc., should be easy by the time I'm done, but that's not going to be before the release.

Also, I can help out with Inkscape if you need it :). It's actually pretty nice, and even if it's somewhere around Blender's skill level, there's less ingenuity needed with SVGs because there aren't any 3D compound curves or texturing problems.

I can't comment on reuseability between different aircraft, but overall I would suggest the more the better.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: SVG editing skills needed

Postby Hooray » Sun Jan 19, 2014 9:03 am

Just to clarify, while it is a combination of all those code files, they don't all need to be understood at all - in fact, Gijs added quite a few new layers recently, without ever looking at the other code - and that was the original plan: 1) copy a set of existing files, 2) customize those, 3) use them - these are typically 2-3 different Nasal files with about ~20-40 lines of code, where usually only a handful of lines need changes, so it's kinda straightforward - and MapStructure itself will even improve things further.

Currently, my priority is helping with the ND code to generalize it further - MapStructure is basically almost there, we already have a demo dialog that uses Philosopher's MapStructure framework to render charts for use in GUI dialogs (PUI) and canvas windows:
Image

The next thing missing here are a handful of additional helpers for mapping/GUI needs, so that property-driven GUI widgets (e.g. PUI stuff) can be easily "linked" to MapControllers (the whole thing still using the MVC separation originally discussed and prototyped).

At that point we can yank a ton of legacy/prototyping code from $FG_ROOT/Nasal/canvas - especially all the map.nas related stuff, because things like the airport selection dialog and the map dialog can be fully re-implemented using roughly 20-50 lines of Nasal code, which is kinda neat obviously.

However, first of all MapStructure needs to be adopted by the ND framework, the map and airport-selection dialogs come next - but once that's done, there's no reason why we cannot get rid of all of the old code, and look into things again to help come up with a framework that also supports PFDs.

The navdisplay.mfd file will need some additional refactoring because recent changes were mostly workarounds, i.e. a ton of custom code was added to things like the update loop - so this will be a good opportunity to re-investigate things and extend the design as needed - ideally, based on feedback from Gijs and Hyde (preferably via the wiki or issue tracker, not via PMs or forum threads - so that things don't get lost over time).

From am design point of view, I would probably introduce a handful of helpers to help with all these tasks:
  • SGSubsystem wrapper for Nasal-based subystems
  • MFDScreen (wrapper for canvases referenced as raster images)
  • MFDImageGenerator (wrapper for a canvas rendering context)
  • MFDSourceSelector (wrapper for assigning different image generators to a single canvas screen)
  • NavDisplay (wip)
  • PrimaryFlightDisplay
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby Hooray » Mon Jan 20, 2014 1:17 pm

zakalawe wrote:Does Inkscape support including a layer from another SVG file?). Since I agree being able to position elements visually is very nice.

The SVG standard explicitly suppots referencing other images (including raster images and SVGs) via the "image" tag - even recursively, so I'd be surprised if inkscape didn't support that.
However, our svg parser doesn't currently support this IIRC - but it's "just" Nasal code, so would probably just require ~10-15 lines of code to add support for the image/object tags.


http://docs.webplatform.org/wiki/tutori ... ent_in_svg
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby pommesschranke » Tue Feb 18, 2014 9:30 pm

In case some1 likes to have it..
I made a PFD.svg following the drawing in the first post on this thread.

https://commons.wikimedia.org/wiki/File ... PFD%29.svg

Image

after I made this, I noticed that there was also a photo under the drawing...
D'oh! :(
Last edited by pommesschranke on Sat Feb 22, 2014 10:43 am, edited 1 time in total.
pommesschranke
 
Posts: 1117
Joined: Sat Apr 27, 2013 8:58 pm
Location: EDLM & LJCE
Callsign: d-laser
IRC name: laserman
Version: git
OS: Linux Kubuntu 22.04

Re: SVG editing skills needed

Postby Hooray » Thu Feb 20, 2014 2:18 pm

thanks for doing this - I would just suggest that people DO NOT take this file now and immediately adapt Gijs' 744 PFD code to just make it work somehow - there's still work remaining to make the PFD code more generic, at the very least, analogous to how the ND code has been sufficiently generalized to be usable in different aircraft and GUI dialogs.

If anybody is interested in working on a PFD variant using Gijs' code, please get in touch to avoid redundant work: http://wiki.flightgear.org/Canvas_PFD_Framework
The main refactoring that needs to be done is:
  • getting rid of global state
  • using hashes, classes and instance variables (me)
  • adding methods
  • supporting multiple independent instances

All the review comments from the original ND discussion are applicable to the PFD, too - I guess, Gijs used the same code as a template, so andybody interested in working on a generic PFD framework, see these two postings for pointers on getting started with a revamped design:

Subject: The making of the Queen
Hooray wrote:Looking at your pfd.nas file currently, does the PFD work properly with multiple instances, i.e. captain/copilot ? Just wondering because I haven't looked at how the code is loaded, but just noticed that you are initializing a bunch of global variables at the top of the script, rather than instance-specific member variables, which I would have expected here ?

For example, consider code like this:
Code: Select all
flaps0 = pfd.getElementById("flaps0");
        flaps1 = pfd.getElementById("flaps1");
        flaps5 = pfd.getElementById("flaps5");
        flaps10 = pfd.getElementById("flaps10");
        flaps20 = pfd.getElementById("flaps20");


so with 2-3 helper functions, and using a vector of lookup keys (for the SVG handles, assuming that the member fields can have identical names) and automatically initializing a corresponding member field then, something along the lines of this (in the constructor):

Code: Select all
# we're in the ctor
var m = { parents: [canvas_PFD] };

var svg_keys = ["flaps0", "flaps1","flaps5", "flaps10", "flaps20"];
foreach(var key; svg_keys) {
m[key] = pfd.getElementById(key);
}


Obviously, this would need some special-case code to deal with updateCenter(); and other init stuff (translation/transform) - but nothing that couldn't be handled via a little helper function and an optional set of parameters, i.e. far less typing/coding required.

I sent a PM to Philosopher asking him how this works under the hood and if it's a safe practice or not - or if I'm just plain wrong :D

what I'd really like to have is to duplicate the displays in dialogs.

You should be able to use an embedded/nested canvas here - where you simply have a single 744 dialog and only ever set the index to the canvas that you want via canvas://by-index/ - Tom also mentioned once that he was going to support lookups by handles, but you can simply use canvas.get( path ) for now.

So, this should just involve:

I'll try to add a tutorial to the wiki once I can run FG again ...

I also need a better way to switch pages on the lower EICAS. Right now I delete/re-create the Canvas

Maybe Tom has a better idea, but I would simply maintain separate pages, either as canvas textures or simply as top-level groups, and then simply .hide() those that you don't want to show - that way, you can keep all pages in the tree, and only show certain pages, without having to delete anything. But Tom should know if there's a better way.

Personally, I would structure the canvas tree for the EICAS based on pages, so that each page is a separate group - and then only ever update the active group (page), while hiding all other groups (pages). That's basically also how the airport selection dialog works internally IIRC, it renders each airport feature (runway, taxiways, tower etc) into a distinct group, so that they can be easily hidden/shown, without having to redraw/update the whole canvas.



Subject: How to display Airport Chart?
Hooray wrote:Okay, Gijs has just committed his code, here's the relevant Nasal bits: https://gitorious.org/fg/fgdata/source/ ... /ND/ND.nas

For generalization, we'll need to remove any use-specific stuff, including listeners, timers, getprop() calls and other hardcoded constraints - those would be better done through function objects/predicates - otherwise, it should be fairly straightforward to move this incrementally to $FG_ROOT/Nasal/canvas/map and use a true MVC approach. Will be getting in touch with Philosopher. If anybody else is interested in working out the requirements/details, please get in touch - or just leave a message here. If there's sufficient interest, we can just as well discuss everything right here.

For styling purposes, it might be better not to draw things procedurally, but instead allow functors or SVG file names to be specified.

@Gijs: Not sure if you have any plans (or time) to further work on this in the coming weeks - but if you do, here's some preliminary feedback to help/simplify our integration work, take it with a grain of salt, depending on feedback from TheTom/Philosopher and Zakalawe. These are some of the changes that I would be making, let me know if you agree/disagree:
  • all your draw* callbacks look similar enough to what's currently used in the MVC stubs, so if you could change the signature accordingly, that would help a lot
  • basically, don't rely on global variables - such as canvas groups, instead pass the group to be rendered to, as an argument to the draw callback
  • instead of having var draw_fix = func (lat, lon, name) you'd use var draw_fix = func (group, lat, lon, name)[/b]
  • you will find that this will also make it much easier to have multiple instances of your instruments, without awkward global state
  • we can then simply add your draw implementations as *.draw files and extending the MVC framework accordingly
  • that will then make it trivial to also show separate/independent dialogs using your exact same code - as in having 10 different NDs, all with different settings, working properly :D
  • signature-wise, I would wrap anything that is specific to the type of symbol in a hash
  • styling: I would use a defaulted argument to check if the "built-in" image is to be drawn, or if a string/filename is provided, or a custom func (nil being default)
  • the range argument is probably what the original "lod" argument was supposed to do - so we can unify that, too ?
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby Hooray » Wed Jul 09, 2014 6:13 pm

@anybody interested in the PFD:

Gijs has started cleaning up the update() method in navdisplay.mfd - once that work is finished, navdisplay.mfd should be down to ~500 lines probably. The ND-specifics should be under 100 lines by then, which means that we can reuse the same code to also port the existing PFD.nas code to use a more flexible approach by coming up with a generic "MFD" class that deals with switches, pages and modes and which merely uses a hash of SVG element IDs and Nasal animation callbacks.

Ultimately, that should allow people to easily provide a customized SVG file and their own animation callbacks.

I am not saying that this approach is "ideal", but it's at least sufficiently generic and flexible without introducing a ton of copy & paste.

The actual integration in ND.nas already is just boilerplate code, and can be easily reduced further by moving identical code to a helper function, which should reduce the whole thing to under 50 lines on the aircraft side.

Regarding the update() method it would be great if some more comments could be added so, in terms of what each conditional should handle, i.e. different modes/settings, so that we can extend the hash instead, to move things there over time.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby Hooray » Fri Aug 22, 2014 9:24 pm

Update: Given the lack of progress in the PFD department, people interested in developing a simple PFD framework should look at Torsten's recent work which is sufficiently generic to support any kind of SVG-based MFD instrument, includinig PFDs and NDs - but also other EICAS/EFIS stuff, e.g. CDUs/EFBs etc.

The relevant aircraft is the ZivkoEdge, and the code is to be found in $FG_ROOT/Aircraft/ZivkoEdge/Models/EFIS (not the most obvious place to look for): https://gitorious.org/fg/fgdata/source/ ... odels/EFIS

As can be seen, Torsten has also started extracting not just EFIS functionality, but also MFD/screen functionality.

For the time being, this must be considered the most mature approach for implementing MFD-functionality in an aircraft, and use-case, agnostic fashion.
So people looking to implement their own MFD-style instruments, should have a look.
Even though it would make sense to obviously move generic code out of the aircraft folder, and specifically support address requirements for a MFD framework and a SVG-based animation framework eventually.

If Torsten's keeps on making this degree of progress, it would probably make sense for "us" (the PFD/ND guys) to look at his code and reuse the generic stuff in the PFD/ND code prototyped by Gijs.

The EFIS.nas file can be found here: https://gitorious.org/fg/fgdata/source/ ... S/EFIS.nas

The other relevant effort is Philosopher's code introduced at: Canvas animations
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: SVG editing skills needed

Postby CaptB » Sat Jul 11, 2015 2:21 pm

Is anybody making Airbus style SVG to use with canvas? I'd gladly join the effort
Ongoing projects(3D modelling): A320, MD-11, A350, B767
FG767: https://fg767.wordpress.com/
CaptB
 
Posts: 685
Joined: Thu May 23, 2013 7:36 pm
Callsign: EKCH_AP
IRC name: CaptB
Version: next
OS: Xubuntu

Re: SVG editing skills needed

Postby Hooray » Sat Jul 11, 2015 4:07 pm

see artix's ND work
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 5 guests