theme: images not shown in print mode?

[cagix]

I noticed that in print mode the images are not being displayed. Is this intended or have I configured something incorrectly?

Example: https://www.hsbi.de/elearning/data/FH-Bielefeld/lm_data/lm_1359639/java-jvm/annotations.html#intellij-inferiert-mit-notnull-mögliche-null-werte looks quite good as intended, but in the print version https://www.hsbi.de/elearning/data/FH-Bielefeld/lm_data/lm_1359639/java-jvm/annotations/index.print.html all the images are missing?

You can find the relevant Hugo configuration at https://github.com/Programmiermethoden/PM-Lecture/blob/master/config.yaml.

Thank you for the great theme!

[McShelby]

Did this work in a previous version of the theme with the same config.toml?

I think the basic reason this is not working as expected comes from the fact that you try to link a resource from a non-page-bundle.

If you change your filesystem structure from

java-jvm
├── images
│   └── screenshot_infer-notnull.png
└── annotations.md

to

java-jvm
└──  annotations
    ├── images
    │   └──  screenshot_infer-notnull.png
    └── _index.md

it should work (I hope - I haven't tested it with your repo yet)

[cagix]

I checked the git history in my repo and at the time of activating the print feature I was already using Hugo Relearn 5.17.1. I'm pretty sure that everything worked as it should have at that time, because I always had problems with the print feature before (cf. https://github.com/McShelby/hugo-theme-relearn/issues/522#issuecomment-1554286717) and was happy that it worked at the time. But: I just noticed that I had been using Hugo 0.114.1 at the time. Maybe that's the reason? I'll have to try it right away.

Edit: Okay, that wasn't the problem. The images are still missing. Interestingly, they are back with the print function of the browser (CTRL-P) - and their layout looks confusingly similar to the print layout of the theme.

[McShelby]

Okay. I'll try to take a look into this in the next days.

Anyways, my advise to change your structure still stands.

[cagix]

If you change your filesystem structure from

java-jvm
├── images
│   └── screenshot_infer-notnull.png
└── annotations.md

to

java-jvm
└──  annotations
    ├── images
    │   └──  screenshot_infer-notnull.png
    └── _index.md

I have now tested your suggestion regarding the folder structure.

In both alternatives, the images are displayed on the "normal" page as expected, but are missing in the print view.

[cagix]

I have been experimenting a little more. When I use a "leaf bundle" (index.md, i.e. without the leading underscore) instead of a "branch bundle" (_index.md), the images in the current theme version are displayed in both the normal and the print view.

But shouldn't branch bundles also work? In the example for branch bundles (https://gohugo.io/content-management/page-bundles/#branch-bundles), Markdown resources seem to be allowed in addition to the _index.md, and that actually works for me - except for the print function of the theme.

(In contrast, the leaf bundle example (https://gohugo.io/content-management/page-bundles/#examples-of-leaf-bundle-organization) clearly states that only the index.md will be rendered and not any other Markdown resources contained in this bundle. Also "single pages" seem to be possible (https://gohugo.io/content-management/organization/#single-pages-in-sections), i.e. Markdown files without _index.md or index.md in the folder? But that could just be a somewhat confusingly written documentation).

Edit: Could this possibly have something to do with my settings? Unfortunately, I have to use uglyurls: true and relativeURLs: false because of my LMS (ILIAS).

[McShelby]

That's really complex as of all the different settings involved.

Can you find a past commit in your repo with an according Hugo version were it worked in the past?

[cagix]

I went through my commit history again. At the time I enabled the print feature, I was using Hugo 0.114.1 and Relearne Theme 5.17.1. I'm pretty sure the print mode was functional then, but when I try to recreate it now with these two versions, the images are still hidden in print mode. Maybe I got it mixed up back then or some other element is at play here?

In my previous comment, I checked that I had some success with "leaf bundles", but not with "branch bundles" and "single pages". Is it perhaps to do with the setting uglyurls: true and relativeURLs: false?

I have attached two screenshots of the same page. It is worth noting that the same image ID(?) is displayed in mouse-over mode, but the image does not seem to be found in print mode.

[McShelby]

I wasn't able to reproduce this with your repo as the setup and dependencies are difficult to aquire.

It would be helpful to have a test branch with all files available to just run hugo server.

I've checked the exampleSite of the theme repo with your settings for uglyurls and relativeURLs and it works for me.

All that said, I also think that there may be something wrong inside of the theme but currently have no clue were to look or how to reproduce it.

Note on print support - take a deep breath: We have a few cases involved:

1. If you are displaying a page, leaf or branch bundle (index.html) in your browser and call the browsers print functionality, it uses the same URL as currently displayed but with CSS media type=print, causing the styles to radically change.
2. If you are displaying the print version of a page or leaf bundle (index.print.hmlt) in your browser, the same radical CSS changes are applied as in 1. but without a media type of print. Depending on Hugo's various URL settings this may result in different directory layouts and makes it necessary for the theme to modify the path to linked files
3. The same as in 2. but for branch bundles. This is different as a branch bundle contains all its subsections and therefore requires further modifications of pathes to linked files for all nested sections.

I suspect the culprit in 2. or 3. but without a simple test case this is just guessing.

[x7peeps]

same problem , can't display image correctly ，i had test it :

This structure works for me to load images successfully java-jvm └── annotations ├── images │ └── screenshot_infer-notnull.png └── _index.md

The usual structure cannot be displayed, sad:< This means that I have to modify the entire structure of my document, which can't be adjusted through framework compatibility. java-jvm ├── images │ └── screenshot_infer-notnull.png └── annotations.md

Hope McShelby can improve compatibility. THX

[McShelby]

@x7peeps The directory outline is a limitiation of Hugo and not the theme. That this may have worked in the first place was an unsupported coincident.

[cagix]

I suspect the culprit in 2. or 3. but without a simple test case this is just guessing.

@McShelby thanks for your investigation. my setup is actually a bit complex and confusing ... i will try to create a mwe and provide it here. i should have done that right away, meakulpa.

The directory outline is a limitiation of Hugo and not the theme.

I'm not quite sure about that. There is an example of "single pages" in the Hugo documentation (https://gohugo.io/content-management/organization/#single-pages-in-sections) - that looks to me like it should work. Especially if these pages are contained in a "branch bundle", i.e. in a folder with an _index.md (see https://gohugo.io/content-management/page-bundles/#branch-bundles), which is actually the case in my example.

[McShelby]

In my understanding, the documentation at some other place seems pretty clear: https://gohugo.io/content-management/page-resources/

In my mind model, any locally referenced file must be part of the page's page resources. But I may be wrong with this assumption.

Anyways, in times of render hooks, this limitation may be raised by theme authors. There are already plans for this theme in #406 and #377 but I fear the aftermath ;-)

[cagix]

@McShelby I made a small MWE with a minimal Hugo configuration: https://github.com/Programmiermethoden/lecture-mwe. There is a landing page _index.md, a leaf bundle leaf/index.md and a branch bundle branch/_index.md, each with a single page resource underneath (leaf/foo.md and branch/bar.md). All pages should include an image from their resources.

As expected, the resource foo in the leaf bundle leaf is not rendered, and the resource bar in the branch bundle branch is.

Somewhat unexpected: The branch bundle branch/_index.md cannot access images in its resource, but the resource branch/bar.md can?!

In print mode, however, the images are missing in both the branch bundle branch/_index.md and the resource branch/bar.md.

---

Edit: I have tested this from the local file system (i.e. not deployed to ILIAS).

Edit: Hugo 0.116.1, Relearn Theme: current via submodule (main)

[McShelby]

Debugging this is painful. I will come up with a longer reply - well - hopefully - soon?!? 🥴

[McShelby]

Follow my lovecraftian adventure live here: https://github.com/McShelby/lecture-mwe.

I am trying to comment each commit either in code or in the commit message.

[McShelby]

Basically this is a duplicate of #406 but let's keep the discussion here.

Before I loose my sanity with this issue (the reason why #406 is still open), I just want to make sure my expectation how this should work matches the public opinion:

Regardless of the uglyurls setting, I would expect my project to generate correct output if I use relative markdown image links based on my projects source directory structure.

Or simplier speaking: If my VSCode editor is displaying the image decorator correctly, the page should work:

To make it clear: This is not the standard behavior of Hugo coming without a render hook for images:

A vanilla Hugo installation (without this theme) makes it necessary to adjust relative markdown image links according to your uglyurls setting, meaning you can't just switch the setting without editing all your relative image links in the source files.

[McShelby]

This may provide a solution: https://www.veriphor.com/articles/link-and-image-render-hooks/

[cagix]

wow - this seems to be quite nasty 😳

Or simplier speaking: If my VSCode editor is displaying the image decorator correctly, the page should work:

this is the way 👍 if github or vscode or obsidian or pandoc can work with this so should hugo. in hugo lingo this is a "page bundle" and all pages in a bundle should have access to the bundle's resources.

A vanilla Hugo installation (without this theme) makes it necessary to adjust relative markdown image links according to your uglyurls setting, meaning you can't just switch the setting without editing all your relative image links in the source files.

this is really strange stuff.

the issue with image "c" not being displayed in _index.md seems to be an upstream issue. if i understand the hugo documentation correctly this simply should work, regardless of uglyurls. that's one of the reasons to use systems like hugo ... perhaps i should open a ticket in the hugo tracker?

regarding the print feature of the theme: i really appreciate your efforts very much, but i also understand (now), that you have to work around nasty limitations (bugs?) of the underlying system (i.e. hugo). if you could find a simple solution that would be great, but don't loose your sanity over this! as i'm already using a somewhat complex workflow including pre-processing markdown files using pandoc, an alternative approach could be to produce a pdf with pandoc via latex. i'd need to work out the "how" as currently the order of the files (i.e. sessions) is specified in the documents metadata and i'd need that information in some build tool ... that's why your theme's print feature was really intriguing to me in the first place 😀

edit: following this thought perhaps i should implement a mechanism like the folks over at mdbook are using: define the structure of the lecture in some markdown document "summary.md" using relative links to the markdown file. this would define also an order on the documents. parsing the links in this document with pandoc i could (a) add the metadata field weight to each document, and (b) transfer each file from wuppie.md to wuppie/_index.md, and (c) parsing and copying the page's resources, and (d) modifying local links on the fly. this should make hugo happier. hmmm 🤔

[cagix]

@McShelby I have experimented a little more: I tried using the figure shortcode from Hugo, and I moved the figures to the top level of the respective bundle.

The figure shortcode (https://github.com/Programmiermethoden/lecture-mwe/commit/68eda5fd48be19b400997d47a8757fa525c5e5e8) works even worse (and looks really terrible compared to the handling in the Relearn theme).

If the images reside toplevel (https://github.com/Programmiermethoden/lecture-mwe/commit/faa032e9df6e79f5db723176d00c8be0387e5f87), then they are rendered correctly for both index.md and _index.md as well as bar.md. In print mode, index.md and _index.md are correct, only bar.md is (still) broken.

TL;DR: I think I really have to take the long route and produce a topic/subtopic/index.md from a "normal" Markdown file topic/subtopicA.md via pre-processing. Everything else seems to be just workarounds - I'm kinda surprised now that everything has worked well so far.

[McShelby]

Before investing to much time on your side, yet, let me just fiddle around with the MWE for a while. Currently I also (same as you) have the feeling, that not everything in Hugo works the way it is documented/expected.

If this is the case, I will open an issue in the Hugo repo.

[McShelby]

I've started to modify your example in my fork. Thanks for getting me started. See the fork for current results (this is still ongoing)

[cagix]

I've started to modify your example in my fork. Thanks for getting me started. See the fork for current results (this is still ongoing)

wow - you truly do a very thorough job!

[McShelby]

I now have a working solution in the test repo which is quite quirky but displays the images in every single case.

It still needs polishing to remove the requirement to upgrade to at least Hugo version 0.114. Also the image attributes are not implemented, yet.

Nevertheless I am a bit hesitant as I have the fear it will run havok in case of edge cases I have overlooked.

Also, I need to test multi lang and all its quirks. Not to speak of tests for aliases and headless bundles

@cagix If you like to test this provisonal state, I could send you the render-link by mail.

[cagix]

I now have a working solution in the test repo which is quite quirky but displays the images in every single case.

that sounds good! thanks for your commitment!

Nevertheless I am a bit hesitant as I have the fear it will run havok in case of edge cases I have overlooked.

i completely agree with you. hugo is already quite complex considering all the options and possible configurations, and the relearn theme adds quite a lot of nice additional features. there is a fairly large chance that something will get overlooked and/or will break during the next update.

in the meantime, i have been pondering this issue. my project layout appears not to be fully compatible with hugo, even though everything has actually worked just fine so far. but who knows, maybe i'm just exploiting a bug or a not well-defined feature and it all breaks with the next hugo upgrade ...

my goal is to provide my users with a (somewhat) working preview and navigation in github and in vscode/obsidian. that's why i don't use the usual hugo bundles "name/index.md", but directly "name.md".

when producing the teaching website with hugo and the relearn theme, all markdown files are being pre-processed with pandoc anyway during the build process. so i should be able to add another transformation step here, which would just have to create the "normal" hugo layout and rewrite all local link targets and image sources on the fly. this should make the print feature work out of the box, shouldn't it?

i can't really anticipate how complex your solution will get and whether it will really fit well with your relearn theme. my idea could probably be implemented in a fairly compact form[^1] with some makefile magic and a few extra pandoc filters. what do you think?

[^1]: shortest computer scientist joke ;)

[x7peeps]

so far ... my web used the structure of my document , looks good. still expect good news～ great theme thanks for your work!

java-jvm
└── annotations
├── java-jvm-guide（a paper title）
│ └── screenshot_infer-notnull.png （the assets）
│ └── _index.md （the markdown content of the “java-jvm-guide”）

[cagix]

@McShelby i've implemented two pandoc filters (https://github.com/cagix/pandoc-lecture/blob/master/filters/hugo_makedeps.lua, https://github.com/cagix/pandoc-lecture/blob/master/filters/hugo_rewritelinks.lua) plus some makefile magic, which allow me to maintain my documents in a github-compatible folder structure, and which will transform this structure during pre-processing into a hugo-compatible structure. this resolves the initial issue regarding the print feature of the relearn theme for me. (at least a short test (https://github.com/cagix/pandoc-lecture/tree/master/demo/hugo-lecture) was working as expected.)

this solution has a neat side effect for me as it will take into account only documents which are referenced via markdown links from the start document (or in any subsequent linked doc) - thus i can build a lecture website containing selected topics for a current semester :) also maintaining the material in a github-compatible structure allows for the students to just use the preview on github.

feel free to close this issue, as it's kind of solved for me.

[McShelby]

There are also changes in Hugo arising, that lift the directory layout limitations of branch bundles: https://github.com/gohugoio/hugo/issues/11439

[McShelby]

Portable linking:

https://stereobooster.com/posts/portable-markdown-links/ https://github.com/bep/portable-hugo-links

[cagix]

this is good news 👍

[postb99]

Well, I personally need to see later why I get a bunch of warnings about my absolute links (not fully absolute because the default language prefix is implicit) when I build my site after upgrading the theme which supports portable links now.

WARN "_index.md": no page was found for link '/en/original_texts/' WARN "_index.md": no page was found for link '/seasons/18_dix_huitieme_saison/la_maison_de_famille/'

However the links work on site (http://poesieland.free.fr/index.html).

<a href="/seasons/18_dix_huitieme_saison/la_maison_de_famille/" class="highlight">La maison de famille, écrit le 24.10.2023</a>

[McShelby]

I've opened a new issue #695 for this.

[McShelby]

Now that Hugo 0.123.0 ist out, get back to the drawing board. Recheck all test and - in best case - everything just works.

That would be like christmas in February.

[cagix]

On my end, everything (including print mode w/ uglyurls) seems to be working just fine. You have done an impressive job! 👍

[McShelby]

Thanks for the feedback. Sounds promising!

[McShelby]

After testing this again with the latest Hugo version 0.123.x it seems as it is now working. Although only to a subset this issue was aiming for.

My initial aim was, to provide users a way to use the same links to pages (other issue) and resources (this issue) regardless of their setting for baseURL and uglyURLs. I internally called that saneURLs.

While this is a heroic aim, Hugo's 0.123 release showed me that this it is not a good idea to work around Hugo's way of doing things. It's kind of a moving target with every Hugo release, changes and bugfixes they apply.

Maybe in the future we all get a solution in Hugo itself.