I decided to start a project which is essentially a website. This website will be published through Github Pages.
My website will include an SVG file. The SVG file is generated by Graphviz from a DOT-file. The idea is that to modify the information displayed in the SVG, users can change the definition of the DOT-file, then Graphviz will re-generate the SVG, and the new SVG image will automatically be displayed once the web page is served.
However, I am left in the uncomfortable situation of requiring contributors who edit the DOT-file to run a script that calls Graphviz, and then commit changes to both the SVG and the DOT file.
If a contributor changes the DOT-file, but forgets to run the Graphviz script, then commits, the repository will contain a DOT-file and an SVG which are inconsistent with each other.
I can't not track versions of the DOT-file, because the SVG is gibberish - the DOT-file is the human-editable definition. I can't not track the SVG, because, how else will it stay up to date and available to Github Pages for consumption? And yet, with both of them tracked, I am essentially keeping track of changes in a redundant manner, and introducing opportunity for conflicts. It's a bit like versioning both your C code and the compiled .exe. Which is silly.
What's the best way of making sure that whenever the DOT-file is edited, the SVG will stay concurrent with it? Do I need to seriously rethink my strategy?
You might consider setting up a Jenkins instance to do this. Create a job that is triggered by a change in the dot file (using the git plugin). The job would execute the dot command and then commit the new svg file.
Generated files should not by committed to your repository.
By default, GitHub Pages uses Jekyll to create sites.
If you are using this workflow, then I would suggest taking a look at writing/using a Jekyll Generator plugin to dynamically create this SVG from your DOT-file.
Related
I know it sounds ridiculous, but Chrome writes to the compiled CSS when using the Developer Tools -> Elements -> Styles with workspace set up. It sees the original partial, but when changing a property, it writes to the compiled (they say it's working as intended, lol). Therefore I would like to:
Watch or intercept 3rd party writes to compiled (changes that didn't occur from the compile due to regular --watch).
Map the change using the sourcemap to the original SCSS file.
Save the changed SCSS file.
That will trigger a new compile. The compiled CSS will probably be the same as how Chrome left it. But this time the values arrive from SCSS and will persist.
I know that if I change stuff on the Sources tab, it does save to the right file. But I don't get a live preview then playing directly with the SCSS file on the Sources tab, only if I save. My workflow includes changing the design live on the Elements -> Style tab, then (for now) copy pasting the values I like to the file. If I have to switch to the Sources tab and I see the unchanged original values there (paste the changes, save, refresh), I might as well just switch to VS Code to do the same thing, it defeats the purpose of how it should work (when no SCSS is thrown into the mix).
I'm using sass from npm but I see this reverse sync would be the task of a custom script that can somehow distinguish the process that wrote to the file to avoid an infinite loop. The files are local but in an Ubuntu VM that has a samba share so they are accessed via a drive letter in Windows (Chrome is told that path). The solution just has to work, I don't care what language or platform.
I have extracted LaTeX content from .tex file, that I put on the website and choose SVG as output, because it provides the smallest possible size so I consider that It will be the best choise also because of his speed and widest versatility. I know, that .js files that contains configurations are cached on the disk in the browser for a few days (depends on the config of the web) or CDN file, but there could be problem with availability of that page, but what about SVG content?
Does it also cache on the disc?
Thank you
Yes and no, depending on what you mean.
For the SVG output, MathJax encodes its "fonts" as path data in JS files, see the code. These paths are cached like any other resource.
But the actual output is generated on the fly from these paths, so the individual equations will not be cached (because making MathJax aware of them would be difficult).
They are stable enough to be reused though, i.e. via local storage and you can generate SVG server side using MathJax-node.
I often write posts with limited or no connectivity, which is one reason octopress is so appealing: it makes it really natural to write and preview posts offline. The problem is that I cannot figure out how to make MathJax play ball. I have it set up and working properly using the CDN, which is how the static pages get uploaded to the server. But what I want is to be able to use a local mathjax to preview the posts offline. This I do not know how to achieve.
To be sure, I can change the source/_includes/custom/head.html point it to ./mathjax/MathJax.js, but that only works if after rake generate I do cp /path/to/mathjax public/. But then I have to do this after every site (re-)generation, which is... cumbersome, to put it mildly. I've tried symbolic links, relative and absolute paths, but to no avail. Is there a better alternative?
Thank you in advance.
If all you need is the MathJax.js, you can put that in source/javascripts/. Doing so will add that file to the Octopress site which in turn means it'll be added to your site every time it's regenerated. source is the base of the Jekyll site Octopress has, so put everything in there except plugins and sass files.
We are considering allowing user uploaded SVGs in our web app. We've been hesitant to do this before, due to a large number of complex vulnerabilities that we know exist in untrusted SVGs. A coworker found the --vacuum-defs option to Inkscape, and believes that it renders all untrusted SVGS safe for processing.
According to the manpage, that option "Removes all unused items from the section of the SVG file. If this option is invoked in conjunction with --export-plain-svg, only the exported file will be affected. If it is used alone, the specified file will be modified in place." However, according to my coworker, "Scripting is removed, XML transformations are removed, malformations are not tolerated, encoding is removed and external imports are removed.
Is this true? If so, is it enough that we should feel safe accepting untrusted SVGs? Is there any other preprocessing we should do?
As I understand it, the main concern of serving untrusted SVGs is the fact that SVG files can contain Javascript. This is obvious for SVG because embedded javascript is part of the format, but it can happen with every type of uploaded file if the browser is not careful.
Therefore, and even though modern browsers do not execute scripts found in the < img > tags, just in case I think it's good to serve the images from a different domain with no cookies/auth attached to it, so that any executed script will not compromise users' data. That would be my first concern.
Of course if the user downloads the SVG and then opens it from the desktop and happens to open it with the browser, it might execute the potentially malicious load. So back to the original question, --export-plain-svg does remove scripting, but as I don't know of other SVG-specific vulnerabilites, I haven't checked for them.
Does CC.NET allow for you to link to premade .html files on the plugin bar on the left?
I know it allows for you to link via XSL, but when I use the XSL for a certain plugin it does not display correctly. But the program can make a .html file itself so i was wondering if i could have it make one then link to it.
I know TeamCity has the capabilities to do this I was just wondering if CC.NET had this too.
And I know about the external links ability, but I want to link to it from the bar on the left, not the main build screen.
Have a look in your webdashboard\templates folder. In there are all the templates the server uses. I think you probably could edit ProjectSideBar.vm and add a normal xxx and use your file name and possibly one of the variables used in the file, something like:
<tr><td>Your File Ouput</td></tr>
I don't know if $projectName exists, but look in the other .vm files and you should be able to find something.
It should work, although I can't check myself at the moment.
Look at the trunk on sourceforge, I just read that in 1.5 is going to be an html plugin on the dashboard for displaying html output...
The Html Report Plugin is what you want to use - it's available starting with release 1.5 as Alex mentioned: http://www.cruisecontrolnet.org/projects/ccnet/wiki/HtmlReportPlugin
EDIT: I've spent a couple of days with the Html Report Plugin and unfortunately it looks like it has too many bugs to be useful. See my issues here and here.