Including vectorgraphics

[Abrynos]

Currently the official guide tells people to manually convert vector graphics to PDF using Inkscape.

I'd like to see the package svg included, which still requires inkscape to be installed, but can include svg files directly using \includesvg{/path/to/image}. Detailed documentation regarding the package can be found here.

[imagingbook]

Since the Inkscape executable must be available -- will this work on Overleaf?

[Abrynos]

will this work on Overleaf?

I have no idea.

[hochleitner]

According to a thread on StackExchange this should work. We'll need to try it out of course.

[Abrynos]

This definitely must be tested, as compilation requires shell escaping to be allowed (e.g. latexmk main -shell-escape)

Or alternatively the files ./svg-inkscape/myImage_svg-tex.pdf_tex and/or ./svg-inkscape/myImage_svg-tex.pdf need to be present.

[hochleitner]

Okay, a short update on this. This seems to work flawlessly in Overleaf as of this date. I created a simple sample project to demonstrate this: https://www.overleaf.com/read/kmcpycwsfddd

Text in SVG images is a bit special since there's the possibility to have it rendered by LaTeX or not. This is the same thing that is being explained in our Inkscape example in section 4.4.4 because this does start from SVG, after all. So I think it's actually just a small step here to include the SVG package and extend the explanation about vector images a bit to have SVG images covered. My example shows both ways - text replaced by LaTeX and as intended. It is visible though, that the replacement is not clean, since there's a linebreak in the original SVG which does not occur when LaTeX renders the text, therefore it's off the baseline.

Locally this is definitely more work than on Overleaf but since almost everyone is using Overleaf nowadays I think this is not so much of an issue.

[hochleitner]

@imagingbook, I'm not fully sure what's the best approach here. Do we simply include the svg package and expand the section on vector graphics or do we create a wiki article about SVG inclusion and without including the package?

If we add the package and expand the tutorial document, I still think we should avoid including an actual SVG image in the document. We should not force people to install Inkscape or have them activate shell escape just to get the tutorial working.

What do you think?

[imagingbook]

I agree, installation of Inkscape should not be required, all docs should compile out of the box on any standard LaTeX installation.

IMHO Sec. 4.4.4 of the tutorial is much too specific and should be simplified. My feeling (from reviewing theses) is that text substitution in vector graphics is practically never used, so this part could be eliminated (moved to the Wiki, as I suggest to do for the svg package). In fact, in our recent book edition I replaced all (i.e., many) such constructs by overpic insertions (as explained in Sec. 4.4.6), which I would promote as the simplest method.

In summary: I suggest to move the entire Inkscape/SVG topic to the Wiki, do a serious cleanup in Ch. 4 and give overpic a more prominent role.

[hochleitner]

I started converting the article about vector graphics with Inkscape into a wiki article: https://github.com/Digital-Media/HagenbergThesis/wiki/Vector-Graphics-with-Inkscape.

Since we can't actually create the images on the fly, as it was the case in the document, I resorted to creating screenshots. Do you think we should also include the SVG file? I could include it as the original image (because the browser can display it), but I'm not sure if it's necessary.

Also, referencing images in Markdown (e.g., see image 1) and images with captions isn't really possible cleanly. I used tables to put a caption below the image.

Please have a look and change things as you see fit.

I'll create a second article on how to include SVG files soon. Once we're satisfied with the wiki articles, I'll remove section 4.4.4 from HgbThesisTutorial.

[imagingbook]

The article looks great! Add yes, I would include (or at least insert a link to) the actual SVG file.

[hochleitner]

What do you think about putting this example in an Overleaf project? Just a simple one-sider that people have read-only access to? This way people can see how the generated files look like and can also download the source files to examine them.
That could be a way to demonstrate small features directly in LaTeX without having to include them in the document. The project is linked in the wiki article and everyone who wants to see some source can have it.

[imagingbook]

@hochleitner Yes, that's the way to go -- I like the idea very much! Could be useful for other topics as well.

[hochleitner]

I created a sample document on Overleaf and referenced it in the wiki article at the very bottom: https://github.com/Digital-Media/HagenbergThesis/wiki/Vector-Graphics-with-Inkscape

The sample document on Overleaf does not include the sty and cls files, it uses the version from CTAN, so we don't have to update these sample projects all the time.

If you want to change something in the sample document, send me your Overleaf user on a less public channel, so I can give you access.

[hochleitner]

The second article about "Including SVGs" is also done: https://github.com/Digital-Media/HagenbergThesis/wiki/Including-SVGs

I've also added an Overleaf sample at the bottom.

Feedback is appreciated. 😄

If this is alright for you, I'll create a PR to remove section 4.4.4.

[imagingbook]

The sample document on Overleaf does not include the sty and cls files, it uses the version from CTAN, so we don't have to update these sample projects all the time.

That's great! But it also means that these demo projects must not use any recent features that are not on CTAN yet. Guess we should upload a new version ASAP...

The second article about "Including SVGs" is also done: https://github.com/Digital-Media/HagenbergThesis/wiki/Including-SVGs

Very nice too, pls. go ahead with the PR.

Package hagenberg-thesis Warning: 
**************************************************************** 
NOTE: 'hagenberg-thesis' is 804 days old - pls. check for updates at https://github.com/Digital-Media/HagenbergThesis
**************************************************************** 
on input line 100.

Haha, at least it's working!

[hochleitner]

PR is out. Please review and merge.

Concerning the new version, three things are still open in the milestone.

1. Content revision: Going through all the documents (mostly HgbThesisTutorial and checking if the content is still up-to-date or if we have outdated links, references to abandoned packages, etc. Also, update the date on the title page.
2. References revision: Going through all Biblatex entries in references.bib and updating them to their latest versions (mainly affecting the referenced packages' manuals).
3. Create an English version of HgbThesisTutorial: this is the big one, but when the above two things are done, I'll make HgbThesisTutorialDE out of HgbThesisTutorial and then create a HgbThesisTutorialEN with the help of DeepL and Grammarly. This means maintaining two example documents in the future, but I guess there's no easy solution to that. It has, however, turned out that our non-German-speaking master's students are usually the ones who are in desperate need of a proper "How to write a thesis in LaTeX" tutorial; this is why I think we should proceed and take up the extra work.

Expect more PRs to come your way. 😬

[imagingbook]

Adding the English tutorial will be most of the work and I'll be happy to help with this. However, in my view it makes no sense to do a 1:1 translation of the current German document, since it needs a general overhaul as well. I agree that both versions should be in sync eventually. I see three alternatives as of how to proceed:

1. Cleanup the German version first and then translate/edit it to English.
2. Translate the German version first and then re-edit/cleanup both versions simultaneously.
3. (cunning) Continue in English only and add separate language-specific parts?

[hochleitner]

I'm currently striving for a option 1 but 2 will definitely come into play.

I'm not planning on doing a 1:1 translation since many German-related content will need to be rewritten to English-centered things and certain phrases probably won't be translatable at all.

But doing an initial DeepL translation followed by going through the whole document and changing things where necessary seems to be the most time-efficient.

Before I'm starting with this, I will finish the content (#141) and literature revision (#142) of the German document. I'm already almost through, expect the PR soon.