Possible issue with listing image .png format

[r-leyshon]

Description

Unsure if I've found a bug, couldn't find the same issue or discussion.

I've been using quarto for my blogsite for a while now. My typical behaviour is to host a JPEG on imgur and to use that for my articles. This image also feeds through fine to index pages which use listings. I usually render my site on macos and push everything up to github and deploy from branch. My site lives here: the datasavvy corner

Right now, I'm working on windows and on a different version of quarto (1.5.56), which could be the cause of my issue.

This time I'm trying to use this PNG in the same way as usual: PNG hosted on imgur

When I run quarto render or quarto render ./index.qmd, I encounter an error. But if I run quarto render ./blogs/index.qmd or quarto render ./blogs/17-quarto-comments.qmd (the doc with the image in the YAML: image: https://i.imgur.com/iCV1fZV.png), I do not encounter the error. My current workaround is to save the file locally & commit to version control. What's peculiar is that previously I have found remote hosting to work fine with JPEG & on macos. Another thing to note: I also use the images in the body of the articles. There, the url PNG renders fine. The issue seems to be in the listing of the main index only. Below is the error:

ERROR: The filename, directory name, or volume label syntax is incorrect. (os error 123): stat 'C:\Users\...\Documents\blogging\https:\i.imgur.com\iCV1fZV.png'

Stack trace:
    at Object.statSync (ext:deno_fs/30_fs.js:425:3)
    at existsSync (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:223:27)
    at imageSize (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:89093:17)
    at renderFeed (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:91039:26)
    at eventLoopTick (ext:core/01_core.js:153:7)
    at async createFeed (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:90878:22)
    at async listingPostProcessor (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:91392:34)
    at async file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:70913:33
    at async withTimingAsync (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:19479:25)
    at async runHtmlPostprocessors (file:///C:/Users/.../AppData/Local/Programs/Quarto/bin/quarto.js:70906:9)

[mcanouil]

Could you share a small self-contained "working" (reproducible) example to work with, i.e., a complete Quarto document or a Git repository? The goal is to make it as easy as possible for us to recreate your problem so that we can fix it: please help us help you! Thanks.

---

You can share a self-contained "working" (reproducible) Quarto document using the following syntax, i.e., using more backticks than you have in your document (usually four ````).
See https://quarto.org/bug-reports.html#small-is-beautiful-aim-for-a-single-document-with-10-lines.

If you have multiple files (and if it is absolutely required to have multiple files), please share as a Git repository.

R	Python
````qmd --- title: "Reproducible Quarto Document" format: html engine: knitr --- This is a reproducible Quarto document. {{< lipsum 1 >}} ```{r} x <- c(1, 2, 3, 4, 5) y <- c(1, 4, 9, 16, 25) plot(x, y) ``` {#fig-placeholder} {{< lipsum 1 >}} The end after @fig-placeholder. ````	````qmd --- title: "Reproducible Quarto Document" format: html engine: jupyter --- This is a reproducible Quarto document. {{< lipsum 1 >}} ```{python} import matplotlib.pyplot as plt x = [1, 2, 3, 4, 5] y = [1, 4, 9, 16, 25] plt.plot(x, y) plt.show() ``` {#fig-placeholder} {{< lipsum 1 >}} The end after @fig-placeholder. ````

Additionally and if not already given, please share the output of quarto check within a code blocks (i.e., using three backticks ```txt), see https://quarto.org/bug-reports.html#check.

[r-leyshon]

@mcanouil Just attempted a minimal reprex (multi file) but cannot easily reproduce the issue. Apologies for time wasted.

[mcanouil]

If you manage to make one, feel free to update the thread.
No apologies needed, we prefer to be aware that there might be a bug rather than be unaware at all.