Linking of figures with refs is inconsistent

[Joaquín Aldunate]

I started using fignos a couple of days ago. Very useful, the filter is greatly appreciated.

I noted an inconsistent behavior leading to "reference fig:b03 not found" warnings. Some cases where I observed this: (note that my text is longer which may be causing the behavior?)

(from md text)

ksk asjas asdjasj (figs. @fig:b03 & @fig:b04).

![ifka sims maia](./res/monos-b-03.png){ width=697px #fig:b03 }

![af sef ef ](.\res/monos-b-04.png){ width=697px #fig:b04 }

in this case it finds fig b04 but not b03.

if I remove the space between figs. and the reference, turning it into
(figs@fig:b03 & @fig:b04).
then it finds both. It seems either as the preceding character affects the readout of the reference, or as if the preceding character makes the label to be parsed by citeproc instead of fignos, since the error message looks like:

pandoc-citeproc: reference fig:b01 not found

perhaps there is a problem with the pattern which matches and consume the tags. I personally thing that the recognition of a fig. should not be affected by the preceding token.

this is the pandoc command:
pandoc ./text.md -s -o ./text.html --filter pandoc-fignos --filter pandoc-citeproc --bibliography="./sources.yaml"

[Joachim K. Rennstich]

I noticed a typo:

![ifka sims maia](./res/monos-b-03.png){ width=697px #fig:b03 }

should prob read

![ifka sims maia](.\res/monos-b-03.png){ width=697px #fig:b03 }

then it would be consistent with the line that worked

![af sef ef ](.\res/monos-b-04.png){ width=697px #fig:b04 }

Hope this helps?

[Thomas J. Duck]

Does @jrennstich's advice solve the problem, @autotel? I'm a bit unfamiliar with the use of backslashes in that manner.

[Joaquín Aldunate]

Hi! No, the problem has no relation with the direction of slashes. The problem remains with consistent forward slashes. I think it might have more relation with the code that matches the ref string.
--edit--
I found another place where both cases occur

MD text:

 that extend the possibilities of the initial set (figs @fig:b03 & @fig:b04).

![Example of emerging components](./res/monos-b-03.png){ width=697px #fig:b03 }

![Additional example of emerging components](./res/monos-b-04.png){ width=697px #fig:b04 }

Result:

--edit 2--
I tried to make it the most likely for the system to find the tags by removing all the other filters from the conversion call (I am converting to ICML)
MD text:

built that extend the possibilities of the initial set (figs {@fig:b03} & {@fig:b04}).

![Example of emerging components](./res/monos-b-03.png){#fig:b03}

![Additional example of emerging components](./res/monos-b-04.png){#fig:b04}

result:

[Joaquín Aldunate]

I tried using the crossref filter, and it produces the same problems; this means that the problem is on how I wrote the references. I cannot find the problem, though.

[Joaquín Aldunate]

I finally found the problem: it had to do not with the referencing itself, but with the breaking lines relation among the images. I will explain since this may help others:
In the examples I provided, I removed a line because I thought it would only distract. This is how my text was originally:
MD text:

built that extend the possibilities of the initial set ([@fig:b03; @fig:b04]).

![graph of the iterative process](./res/monos-b-01.png){#fig:b01 width=30%}
![Example of emerging components](./res/monos-b-03.png){#fig:b03 width=30%}

![Additional example of emerging components](./res/monos-b-04.png){#fig:b04 }

I removed the line containing the fig b01, because I thought it was not related to the problem and would make reading easier. I ran into this caveat:

This only works on implicit figures, i.e. an image occurring by itself in a paragraph (which will be rendered as a figure with caption by pandoc)
(from https://hackage.haskell.org/package/pandoc-crossref-0.2.5.0)

My figure is not strictly within the text, but it had a single break instead of a double break, which the working figure does have. Probably the MD parser considered the single break as no break at all. This is sad, because the nice thing about writing in MD is not having to deal with counter-intuitive problems that other formats may have.

In short, the way to solve the not-found figure references is to separate all the target figures with at least to line breaks.

[Thomas J. Duck]

Yes, pandoc requires figures to be in their own paragraph. I'm glad that you were able to sort it out.

Cheers,
Tom