Comments (10)
That's a very charming idea. I will try to implement that in the next version.
from svg.
In my workflow, I often replace svg files (that are auto generated with my own tools).
Currently, I always have to manually delete the generated files in the "svg-inkscape" folder to get a new variant of the svg file compiled.
Hence, I think, rather than hashing the file path, it would probably make more sense to compute a hash based on the svg content?
(Then in an unlikely event of having duplicate svgs at different locations, it would even be enough to generate the PDFs once.)
Edit. I just noticed, that it is unnecessary to delete the svg-inkscape folder because of updated svgs: The detection is already done via the modified date 😍 .
(However, I'll leave my comment here, maybe it is still a good idea to hash based on the contents rather than the file path?)
from svg.
Hence, I think, rather than hashing the file path, it would probably make more sense to compute a hash based on the svg content?
(Then in an unlikely event of having duplicate svgs at different locations, it would even be enough to generate the PDFs once.)
The thing is that one can have identical svg files in different locations each referencing external image files via relative paths. In this case, the svg files can produce different-looking images even though their hashes are identical.
So, one would need to preprocess the svg files by replacing relative paths with absolute ones before computing the hashes, or compute hashes of these linked files as well.
I would say it's not worth the extra trouble.
from svg.
You're right, I was not thinking about referencing external files!
Maybe it is still easier to use hash(fileName + fileContents)
instead of monitoring the modifiedDate when it comes to updating svg files. However, I guess that's up to the implementer / maintainer :)
from svg.
That's exactly how I would implement it, appending the path hash to the file name. As I said before, however, I unfortunately lack the time to work on it right now.
from svg.
ah I guess I could use the option inkscapepath=svgsubdir
from svg.
although .. having the generated pdf(_tex) files in a single directory is quite elegant since this directory can then later be deleted to save storage.
Wouldn't it make sense to compute a hash string from the path to the svg file and then use that hash as a unique file name in the default subfolder svg-inkscape?
from svg.
Maybe it is still easier to use
hash(fileName + fileContents)
instead of monitoring the modifiedDate when it comes to updating svg files. However, I guess that's up to the implementer / maintainer :)
This would mean that old versions in svg-inkscape
are never overwritten, so the svg-inkscape
directory will get bloated over time if you edit your images a lot. (One could of course devise some garbage collector routine, but this comes with its own disadvantages (e.g. it would discard data when only partially compiling the document) and is an unnecessary complication, I think.) I see no disadvantage in just hashing the file path and using the date to detect changes as it has been done now.
One workflow that has not been mentioned here before is editing the pdf_tex
file after it has been created. While not very common, this can sometimes be useful and is explicitely supported by the package: If the pdf_tex
file has been edited, i.e. it is newer than the pdf
file, those files are never overwritten, even if the original svg
file is still newer. (Instead, the user is warned about this.) This possibility should be preserved, which is another reason against hashing the file contents.
However, just using the file path hash as the file name in svg-inkscape
would also complicate this workflow a lot, since one would first have to determine the correct hash to find the right pdf_tex
file to edit. That's why I would propose preserving the original filename in svg-inkscape
and only appending the path hash. (So for example \includesvg{img/test}
would lead to test_⟨hash of the absolute path of "img/test"⟩.pdf
being created.)
from svg.
As temporary workaround (not that flexible) I am using the passed image file path.
\makeatletter
\newcommand{\includesvggraphics}[2][\textwidth]{%
\filename@parse{#2}%
\includesvg[inkscapepath=svg-inkscape/\filename@area,width=#1]{#2}%
}
\makeatother
Usage:
\includesvggraphics{experiments/datasets/mnist.svg}
% or
\includesvggraphics[.5\textwidth]{experiments/datasets/mnist.svg}
Output:
svg-inkscape
└── experiments
└── datasets
└── mnist_svg-raw.pdf
Maybe it will help someone until the hash solution is implemented.
from svg.
A useful workaround though I won't implement this variant, since this wouldn't work with absolute or relative paths---pointing to folders outside the project directory.
from svg.
Related Issues (20)
- Including some files from matplotlib fails, commandline works HOT 2
- Importing SVG doesn't work on Windows when the filename contains German special characters
- No helpful error message when inkscape conversion fails HOT 5
- Rendering twice removes the output HOT 1
- \includesvg in Beamer causing wrong figure placement HOT 6
- Bug color/colour of text not correct HOT 2
- Inkscape conversion command deprecated for Inkscape 1.2.2 (2022-12-09) HOT 5
- SVG extracted using `svg-extract` looks different from the original SVG HOT 4
- `svg` package takes the bounding box of the original SVG as opposed to the bounding box resulting from the text conversion HOT 2
- Exporting selected layers HOT 3
- Including two files by the same name results in duplication of the first file HOT 1
- Call inkscape --shell with batches of files for faster processing HOT 4
- Handling for package `svg-extract` only options is flawed when used with package `svg` instead
- TeXstudio autocomplete is not supported by svg package HOT 6
- add support for opt-in ImageMagick instead of Inkscape HOT 4
- Compilation fails for specific images
- Text Reference Displays Section Number Instead of Figure Number with \ref HOT 1
- svg-extract incompatibility with filecontents HOT 1
- includesvg incompatible with setkeys{Gin} HOT 16
- Enhanced support for pandoc HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svg.