I have just uploaded a new version of SetupManual. This re-launch of the service re-defines the workflow in favour of user-generated content via a simple HTML5 SVG editor.
It's *very* rough around the edges and due to various HTML5 issues (standards!) works only in versions of Mozilla Firefox after 6.x .
There's an SVG (xml namespace) bug in Chrome which prevents it from working properly. Safari and IE9 has no/incomplete support for the HTML5 File APIs, and IE8 crashes viciously when creating an SVG DOM object.
So now that you're aware of the minefield and if you're still interested in having a go, I am looking forward to your frank no-holds-barred feedback :-)
thanks for the introduction to the map of the minefield!
im surprised to hear this svg dom element creation bug.
andras and me played around w dynamic svg too.
here is one of his projects:
http://sullerandras.github.com/SVG-Sequence-Diagram/ i dont think it crashes on ie8, although we just let angularjs
to create the svg dom elements…
the file api is terrible, i must confirm too…
you know what i miss? specs for these things.
why did they make the api this way?
what were they thinking how ppl will want to use it?
for example i would think it's a pretty standard requirement
to upload a directory hierarchy.
or select multiple files and directories and let browser
walk thru them in depth.
but apparently it's not possible.
(needless to say such sandboxing functionality was
already solved in rebol 10+yrs ago, but oh well…
welcome to the great IT devolution...)
On Friday, May 11, 2012 at 10:15 PM, Stephan February wrote:
> Hello
> I have just uploaded a new version of SetupManual. This re-launch of the service re-defines the workflow in favour of user-generated content via a simple HTML5 SVG editor.
> It's *very* rough around the edges and due to various HTML5 issues (standards!) works only in versions of Mozilla Firefox after 6.x .
> There's an SVG (xml namespace) bug in Chrome which prevents it from working properly. Safari and IE9 has no/incomplete support for the HTML5 File APIs, and IE8 crashes viciously when creating an SVG DOM object.
> So now that you're aware of the minefield and if you're still interested in having a go, I am looking forward to your frank no-holds-barred feedback :-)
On 12 May, 2012, at 10:43 PM, Tamas Herman <hermanta...@gmail.com> wrote:
> hey stephan,
> thanks for the introduction to the map of the minefield!
> im surprised to hear this svg dom element creation bug.
> andras and me played around w dynamic svg too.
> here is one of his projects:
> http://sullerandras.github.com/SVG-Sequence-Diagram/ > i dont think it crashes on ie8, although we just let angularjs
> to create the svg dom elements…
I finally managed to work around the bug, and can happily report that both Chrome and Firefox are now supported for SetupManual. The problem is that Chrome does not honor the xlink:href namespace. So when I send my SVG from the browser to the server for rasterization the server-side library crapped out 'cause of the broken SVG standards compliance in Chrome. I ended up manually patching the broken xlink: references in Javascript right before sending to the server, so everyone's happy.
I'm using RaphaelJS for javascript SVG manipulations client-side, and Apache Batik server-side.
On Saturday, May 12, 2012 at 11:31 PM, Stephan February wrote:
> I finally managed to work around the bug, and can happily report that both Chrome and Firefox are now supported for SetupManual.
> The problem is that Chrome does not honor the xlink:href namespace. So when I send my SVG from the browser to the server for rasterization the server-side library crapped out 'cause of the broken SVG standards compliance in Chrome. I ended up manually patching the broken xlink: references in Javascript right before sending to the server, so everyone's happy.
i see, thx for the details.
> I'm using RaphaelJS for javascript SVG manipulations client-side, and Apache Batik server-side.
looks like it's a pretty common problem, that ppl want to rasterize stuff what's possible to produce w a browser, although browsers are everywhere, so theoretically it should not be necessary…
as i see the main reason is to wrap the used resources into 1 file, specifically pdf.
i think it's favored over any other solution, because it's definition is less open ended as html+css+xxx, so the output of the various implementations on the various platforms are not so different.
i almost said the other reason is pdf is more like data and not a program, but it's not entirely true, since its core is postscript, which is effectively a version of forth.
3rd reason might be to fix and map the layout to a specific physical paper size; which im not sure is always wanted actually…
4th reason comes from the fact it's just 1 file, so it's possible to encrypt and digitally sign it.
im summarizing so it might ignite other ppl's imagination and also to ask:
why do we need to use a different implementation on the backend for rendering from what we use on the frontend?
webkit is available on the backend too… phantomjs nicely wraps it and turns it into a command line tool effectively. just use the bundled rasterize.js example as is to generate pdf or png/jpg.
what's missing probably is an example how can we setup phantomjs as a web service with runtime and process count constraints. i can imagine this could be a little startup on it's own… similarly graphviz could be wrapped into a service… maybe it's time for me to sit down and jfdi...
> On Saturday, May 12, 2012 at 11:31 PM, Stephan February wrote:
> > I finally managed to work around the bug, and can happily report that
> both Chrome and Firefox are now supported for SetupManual.
> > The problem is that Chrome does not honor the xlink:href namespace. So
> when I send my SVG from the browser to the server for rasterization the
> server-side library crapped out 'cause of the broken SVG standards
> compliance in Chrome. I ended up manually patching the broken xlink:
> references in Javascript right before sending to the server, so everyone's
> happy.
> i see, thx for the details.
> > I'm using RaphaelJS for javascript SVG manipulations client-side, and
> Apache Batik server-side.
> looks like it's a pretty common problem, that ppl want to rasterize stuff
> what's possible to produce w a browser, although browsers are everywhere,
> so theoretically it should not be necessary…
> as i see the main reason is to wrap the used resources into 1 file,
> specifically pdf.
> i think it's favored over any other solution, because it's definition is
> less open ended as html+css+xxx, so the output of the various
> implementations on the various platforms are not so different.
> i almost said the other reason is pdf is more like data and not a program,
> but it's not entirely true, since its core is postscript, which is
> effectively a version of forth.
> 3rd reason might be to fix and map the layout to a specific physical paper
> size; which im not sure is always wanted actually…
> 4th reason comes from the fact it's just 1 file, so it's possible to
> encrypt and digitally sign it.
> im summarizing so it might ignite other ppl's imagination and also to ask:
> why do we need to use a different implementation on the backend for
> rendering from what we use on the frontend?
> webkit is available on the backend too… phantomjs nicely wraps it and
> turns it into a command line tool effectively. just use the bundled
> rasterize.js example as is to generate pdf or png/jpg.
> what's missing probably is an example how can we setup phantomjs as a web
> service with runtime and process count constraints. i can imagine this
> could be a little startup on it's own… similarly graphviz could be wrapped
> into a service… maybe it's time for me to sit down and jfdi...
Yes the app has moved from restricting users to a predefined set of templates to being 100% user generated content. The user takes their screenshots and using the client-side HTML5 SVG editor creates their own custom step-by-step manuals.
I've tested on Ubuntu 11.10 and while the default install of Firefox 7.0.1 crashes, Firefox 12 on Ubuntu works fine.
Checkout the video on the landing page for an idea of how the new workflow works.
Cheers
Stephan
Sent
On 13 May, 2012, at 4:01 AM, Benjamin Scherrey <proteus...@gmail.com> wrote:
> We no longer have a windows capture dependency? I can use your system with linux now?
> -- Ben
> On Sat, May 12, 2012 at 10:55 PM, Tamas Herman <hermanta...@gmail.com> wrote:
> On Saturday, May 12, 2012 at 11:31 PM, Stephan February wrotei:
> > I finally managed to work around the bug, and can happily report that both Chrome and Firefox are now supported for SetupManual.
> > The problem is that Chrome does not honor the xlink:href namespace. So when I send my SVG from the browser to the server for rasterization the server-side library crapped out 'cause of the broken SVG standards compliance in Chrome. I ended up manually patching the broken xlink: references in Javascript right before sending to the server, so everyone's happy.
> i see, thx for the details.
> > I'm using RaphaelJS for javascript SVG manipulations client-side, and Apache Batik server-side.
> looks like it's a pretty common problem, that ppl want to rasterize stuff what's possible to produce w a browser, although browsers are everywhere, so theoretically it should not be necessary…
> as i see the main reason is to wrap the used resources into 1 file, specifically pdf.
> i think it's favored over any other solution, because it's definition is less open ended as html+css+xxx, so the output of the various implementations on the various platforms are not so different.
> i almost said the other reason is pdf is more like data and not a program, but it's not entirely true, since its core is postscript, which is effectively a version of forth.
> 3rd reason might be to fix and map the layout to a specific physical paper size; which im not sure is always wanted actually…
> 4th reason comes from the fact it's just 1 file, so it's possible to encrypt and digitally sign it.
> im summarizing so it might ignite other ppl's imagination and also to ask:
> why do we need to use a different implementation on the backend for rendering from what we use on the frontend?
> webkit is available on the backend too… phantomjs nicely wraps it and turns it into a command line tool effectively. just use the bundled rasterize.js example as is to generate pdf or png/jpg.
> what's missing probably is an example how can we setup phantomjs as a web service with runtime and process count constraints. i can imagine this could be a little startup on it's own… similarly graphviz could be wrapped into a service… maybe it's time for me to sit down and jfdi...
