Site Sponsors:
Fixing SVC.XML Errors in Apache Batik 
It was 2AM. Well into the 1st shift for my day.

Having just enthusiastically created 20 images for use in a 2D attack simulator, I was eager to get those Inkscape designs into my Java simulator.

Upon noticing that even the Linux OS I was using was unable to display thumbnails for the images in-question, I should have know that something was going wrong. Undaunted however, I rather venially tried to load the XML files as saved by Inkscape.

What part of the word "boom" did I not understand?

After the usual & customary 'googling, it became apparent that the problem was that Inkscape was using absent-classes to control bits of undo, layering, and other XML snippets that were simply not to be found in the Apache Batik Framework. After that epiphany, the quick-and-easy work-around became obvious.

(HINT: The use of additional JAR files were NOT required!)

Submitted for your R&D approval therefore, please consider this link so as to slap me with .02 for taking the time to share the solution to what - for many - has proven to be a real show-stopper to re-using output from many an SVG.XML program in their own - as well as in other people's - vector-laden software creations.

Sharing might indeed be caring, but gifting your fellow 'geeks with pennies from YouTube is one nice way to return the favors.


Enjoy the Journey!

-Rn



Google Fodder:

org.w3c.dom.DOMException: The current document is unable to create an element of the requested type (namespace: http://www.w3.org/2000/svg, name: flowRoot).
at org.apache.batik.dom.AbstractNode.createDOMException(Unknown Source)
at org.apache.batik.anim.dom.SVGDOMImplementation.createElementNS(Unknown Source)
at org.apache.batik.anim.dom.SVGOMDocument.createElementNS(Unknown Source)
at org.apache.batik.dom.util.SAXDocumentFactory.startElement(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source)
at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.DTDConfiguration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.dom.util.SAXDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.anim.dom.SAXSVGDocumentFactory.createDocument(Unknown Source)
at org.apache.batik.anim.dom.SAXSVGDocumentFactory.createSVGDocument(Unknown Source)
at org.apache.batik.bridge.DocumentLoader.loadDocument(Unknown Source)
at org.apache.batik.swing.svg.SVGDocumentLoader.run(Unknown Source)




[ add comment ]   |  permalink  |  related link
Managing LS_COLORS 
While it is nice to have a colorized console, the default colors of 'light blue on green' for executable directories is unable to be read by anyone in my native hemisphere:


Yikes.

For those whom might want to change these default colors, two approaches to getting back to basics are possible.

Can the Colors


The first option is to simply junk the colorization all-together.


On Ubuntu and elsewhere, we can return to the 1970's by simply changing the alias from '--color=auto' to '--color=never' in our session-starting ~/.bashrc file.

Mod the Colors


The next option is to simply modify the colors. In this case, the offensive color selection is managed by ow=. To change it, simply add
LS_COLORS=$LS_COLORS'ow=0;93:' ; export LS_COLORS
to the end of your ~/.bashrc file:


For more information, you might also wish to see if 'dircolors' is part of your 'distro:

LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:';
export LS_COLORS


Other 'Distros


Better still, using `dircolors -p > .dir_colors` in our home directory SHOULD help allot (the omission was a performance decision), but did not help at-all on Ubuntu.

If it worked, then changing 'OTHER_WRITABLE 34;42' in the new .dir_colors would modify the color in question to something like 01;33 -- a setting that most homosapiens could read.

NOTE: As usual, please understand that one will have to exit any existing sessions so as to re-apply any .bahsrc changes.


Enjoy the journey,


-Rn







[ add comment ] ( 19 views )   |  permalink  |  related link

| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | Next> Last>>