docling-project__docling-2983

The user is reporting a crash in `AsciiDocBackend._parse_picture()` when the image alt text contains commas.
The issue is that the code splits by comma and expects `key=value` pairs for everything after the first element (alt text).
If the alt text has commas, it breaks the unpacking.

Example content causing crash:
`image::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]`

The current logic likely does something like:
```python
parts = bracket_content.split(",")
alt_text = parts[0]
for part in parts[1:]:
    key, value = part.split("=", 1)
```
If `alt_text` contains commas, `parts[1]` might be a continuation of the alt text and not contain an `=`.

Let's locate `AsciiDocBackend._parse_picture()` in `docling/backend/asciidoc_backend.py`.

{
  "command": "grep -rn --include=\"*.py\" \"_parse_picture\" ."
}

{
  "status": "ok",
  "stdout": "./docling/backend/asciidoc_backend.py:204:                item = self._parse_picture(line)\n./docling/backend/asciidoc_backend.py:404:    def _parse_picture(line):\n./tests/test_backend_asciidoc.py:25:def test_parse_picture():\n./tests/test_backend_asciidoc.py:29:    res = AsciiDocBackend._parse_picture(line)\n./tests/test_backend_asciidoc.py:36:    res = AsciiDocBackend._parse_picture(line)\n",
  "stderr": "",
  "exit_code": 0
}

Okay, the method is in `docling/backend/asciidoc_backend.py` at line 404.
Let's examine the code around that method.

{
  "end_line": 450,
  "filepath": "docling/backend/asciidoc_backend.py",
  "start_line": 400
}

{
  "status": "ok",
  "filepath": "docling/backend/asciidoc_backend.py",
  "content": "    def _is_picture(line):\n        return re.match(r\"^image::\", line)\n\n    @staticmethod\n    def _parse_picture(line):\n        \"\"\"\n        Parse an image macro, extracting its path and attributes.\n        Syntax: image::path/to/image.png[Alt Text, width=200, height=150, align=center]\n        \"\"\"\n        mtch = re.match(r\"^image::(.+)\\[(.*)\\]$\", line)\n        if mtch:\n            picture_path = mtch.group(1).strip()\n            attributes = mtch.group(2).split(\",\")\n            picture_info = {\"type\": \"picture\", \"uri\": picture_path}\n\n            # Extract optional attributes (alt text, width, height, alignment)\n            if attributes:\n                picture_info[\"alt\"] = attributes[0].strip() if attributes[0] else \"\"\n                for attr in attributes[1:]:\n                    key, value = attr.split(\"=\")\n                    picture_info[key.strip()] = value.strip()\n\n            return picture_info\n\n        return {\"type\": \"picture\", \"uri\": line}\n\n    #   =========   Captions\n    @staticmethod\n    def _is_caption(line):\n        return re.match(r\"^\\.(.+)\", line)\n\n    @staticmethod\n    def _parse_caption(line):\n        mtch = re.match(r\"^\\.(.+)\", line)\n        if mtch:\n            text = mtch.group(1)\n            return {\"type\": \"caption\", \"text\": text}\n\n        return {\"type\": \"caption\", \"text\": \"\"}\n\n    #   =========   Plain text\n    @staticmethod\n    def _parse_text(line):\n        return {\"type\": \"text\", \"text\": line.strip()}",
  "start_line": 400,
  "end_line": 443,
  "total_lines": 443,
  "is_truncated": false
}

The bug is exactly where I suspected:

```python
            attributes = mtch.group(2).split(",")
            picture_info = {"type": "picture", "uri": picture_path}

            # Extract optional attributes (alt text, width, height, alignment)
            if attributes:
                picture_info["alt"] = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    key, value = attr.split("=")
                    picture_info[key.strip()] = value.strip()
```

If `mtch.group(2)` is `A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422`, then `attributes` will be:
`['A screenshot showing a dialog box', ' containing text fields', ' buttons', ' and validation errors', ' width=604', ' height=422']`

The loop `for attr in attributes[1:]` will start with `attr = ' containing text fields'`, and `attr.split("=")` will result in `[' containing text fields']`, and `key, value = attr.split("=")` will raise `ValueError: not enough values to unpack (expected 2, got 1)`.

We need to handle cases where the attribute does not contain `=`.
According to AsciiDoc syntax, the first attribute is typically the alt text, and subsequent ones are `key=value` pairs. But if the alt text contains commas, the current split is too naive.

Wait, if the alt text can contain commas, how do we know where the alt text ends and the attributes begin?
Actually, in AsciiDoc `image::`, the brackets `[...]` contain attributes. The first one is the alt text.
If the alt text contains commas, it should probably be quoted? Or maybe the parser should check if the attribute contains an `=` before trying to unpack it.

If it doesn't contain `=`, it's probably just part of the alt text. But wait, the alt text is the *first* element. If we have:
`[Alt text, with comma, width=100]`
Then:
`attributes[0]` is `Alt text`
`attributes[1]` is ` with comma` (no `=`)
`attributes[2]` is ` width=100` (has `=`)

If we want the alt text to be "Alt text, with comma", we should probably accumulate all attributes that don't have an `=` into the alt text, or just recognize that the alt text can span multiple comma-separated segments until we hit a `key=value` pair.

Wait, if the alt text is `Alt text, with comma`, the actual result expected by the user is probably that the alt text should contain the commas.

Let's look at the reproduction case:
`image::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]`
Here, alt text is `A screenshot showing a dialog box, containing text fields, buttons, and validation errors`.
And attributes are `width=604` and `height=422`.

So the logic should be:
1. Split by comma.
2. The first element is always part of the alt text.
3. Subsequent elements are either part of the alt text (if they don't contain `=`) or are key-value pairs.

Correct. Let's check if there are other attributes that might not have `=`. According to AsciiDoc specs, attributes in `[...]` are generally `key=value` pairs, except the first one which is the alt text.

But wait, what if the alt text itself contains `key=value`? That's unlikely but possible. However, for the common case of auto-generated exports, the comma is the delimiter and we should be flexible.

A better approach:
Iterate through the split parts. If a part contains `=`, treat it as a key-value pair. If it doesn't, and it's before any key-value pair, it's part of the alt text. Wait, what if it's *after* a key-value pair?
AsciiDoc usually has alt text first.

Let's refine the logic:
```python
            if attributes:
                # Initial alt text from the first element
                alt_text_parts = [attributes[0].strip()]
                
                # We need to keep track of which parts are kv pairs and which are alt text
                # Actually, the most robust way is to find the first part that looks like a kv pair
                # but everything before that is part of the alt text.
                # What if there are no kv pairs? Then all are part of alt text? No, that's too much.
                
                # Let's try this:
                alt_text = attributes[0].strip()
                for attr in attributes[1:]:
                    if "=" in attr:
                        key, value = attr.split("=", 1)
                        picture_info[key.strip()] = value.strip()
                    else:
                        # It's a continuation of the alt text (if we haven't found kv pairs yet?)
                        # Or just append it to alt text.
                        alt_text += ", " + attr.strip()
                picture_info["alt"] = alt_text
```

Wait, if I have `[Alt text, width=100, something else]`. Is "something else" part of alt text?
Usually, attributes are `alt, width=X, height=Y`.

If we have `[Alt text with comma, width=100]`, then `attributes` is `['Alt text with comma', ' width=100']`.
`attributes[0]` is `Alt text with comma`.
`attributes[1]` is ` width=100`.

Wait, in the reproduction case:
`[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]`
`attributes` is `['A screenshot showing a dialog box', ' containing text fields', ' buttons', ' and validation errors', ' width=604', ' height=422']`

My proposed logic:
`alt_text` starts as `A screenshot showing a dialog box`.
`attr` = ` containing text fields` -> no `=`, so `alt_text` becomes `A screenshot showing a dialog box, containing text fields`.
`attr` = ` buttons` -> no `=`, so `alt_text` becomes `A screenshot showing a dialog box, containing text fields, buttons`.
... and so on until `width=604`.

This seems to match the user's expectation.

Wait, let's verify if the first attribute is always the alt text.
`image::path[alt text, width=100]` -> `alt text` is `attributes[0]`.
`image::path[width=100]` -> `attributes[0]` is `width=100`. In this case, `alt` should be empty and `width` should be 100.

Current code:
```python
                picture_info["alt"] = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    key, value = attr.split("=")
                    picture_info[key.strip()] = value.strip()
```
If `attributes[0]` is `width=100`, current code sets `picture_info["alt"] = "width=100"`, which is probably wrong.

Wait, looking at AsciiDoc documentation, the first attribute is indeed the alt text. If the alt text is omitted, it starts with `[` then the comma-separated attributes. But if the first one is `width=100`, is it the alt text or the width?
In AsciiDoc, if you want to omit the alt text, you can start with a comma: `image::path[,width=100]`.
In that case `attributes[0]` would be `""`.

If the user writes `image::path[width=100]`, then `width=100` *is* the alt text.

So my proposed logic:
```python
            if attributes:
                alt_text = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    if "=" in attr:
                        key, value = attr.split("=", 1)
                        picture_info[key.strip()] = value.strip()
                    else:
                        # Append to alt text if it's just a string
                        if alt_text:
                            alt_text += ", " + attr.strip()
                        else:
                            alt_text = attr.strip()
                picture_info["alt"] = alt_text
```
Wait, what if `attributes[0]` already contains an `=`?
If `image::path[width=100, height=200]`, then `attributes[0]` is `width=100`.
The current code sets `alt` to `width=100` and then sets `height` to `200`.
This seems to be the intended behavior of the current code (except it crashes on missing `=`).

If the user wants to skip alt text, they should use `[,width=100]`.
If they use `[width=100]`, `width=100` is the alt text.

So if we just want to fix the crash and keep the behavior as close as possible:
Just skip the attributes that don't contain `=`, or better, append them to the alt text if they don't contain `=`.

Wait, if the first element is `width=100`, and the second is `height=200`, `attributes[0]` is `width=100`. We don't want to treat it as alt text if it's clearly a KV pair?
No, in AsciiDoc, the first positional argument is always the alt text.

Actually, the most robust way is:
The first element is always the alt text.
Every subsequent element is a KV pair if it contains `=`, otherwise it's part of the alt text.

Let's test this hypothesis.
`[Alt text, width=100]` -> `attributes[0]`="Alt text", `attributes[1]`="width=100". Result: alt="Alt text", width=100.
`[Alt text with comma, width=100]` -> `attributes[0]`="Alt text with", `attributes[1]`=" comma", `attributes[2]`="width=100". Result: alt="Alt text with, comma", width=100.
`[width=100, height=200]` -> `attributes[0]`="width=100", `attributes[1]`="height=200". Result: alt="width=100", height=200. (This is correct for AsciiDoc if no comma is at start).
`[,width=100, height=200]` -> `attributes[0]`="", `attributes[1]`="width=100", `attributes[2]`="height=200". Result: alt="", width=100, height=200.

Wait, if `attributes[0]` is `width=100` and `attributes[1]` is `height=200`, we probably want `alt` to be empty if `attributes[0]` looks like a KV pair?
No, if the first thing in the brackets is not preceded by a comma, it's the alt text.

Let's check the reproduction again.
`image::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]`
`attributes[0]` = `A screenshot showing a dialog box`
`attributes[1]` = ` containing text fields` (no `=`) -> alt
`attributes[2]` = ` buttons` (no `=`) -> alt
`attributes[3]` = ` and validation errors` (no `=`) -> alt
`attributes[4]` = ` width=604` (has `=`) -> key=width, value=604
`attributes[5]` = ` height=422` (has `=`) -> key=height, value=422

This works perfectly.

One more thing: `attr.split("=")` should be `attr.split("=", 1)` to handle cases where the value might contain an `=`.

Let's reproduce the bug first.

{
  "command": "python3 - <<'PY'\nfrom docling.document_converter import DocumentConverter\nfrom docling.datamodel.base_models import InputFormat\nfrom pathlib import Path\nimport tempfile\nimport os\n\n# Minimal .adoc file with commas in alt text\ncontent = \"\"\"= Test Document\n\nimage::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]\n  \"\"\"\n\nwith tempfile.NamedTemporaryFile(suffix=\".adoc\", mode=\"w\", delete=False) as f:\n    f.write(content)\n    tmp_path = Path(f.name)\n\ntry:\n    converter = DocumentConverter(allowed_formats=[InputFormat.ASCIIDOC])\n    result = list(converter.convert_all(source=[tmp_path], raises_on_error=False))\n    print(f\"Status: {result[0].status}\")\n    print(f\"Errors: {result[0].errors}\")\nfinally:\n    if tmp_path.exists():\n        os.remove(tmp_path)\nPY\n"
}

{
  "status": "ok",
  "stdout": "Status: failure\nErrors: [ErrorItem(component_type=<DoclingComponentType.PIPELINE: 'pipeline'>, module_name='SimplePipeline', error_message='not enough values to unpack (expected 2, got 1)')]\n",
  "stderr": "",
  "exit_code": 0
}

Reproduction successful. Now I will implement the fix.

I'll double check the code I'm replacing.
```python
            if attributes:
                picture_info["alt"] = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    key, value = attr.split("=")
                    picture_info[key.strip()] = value.strip()
```

I will replace it with:
```python
            if attributes:
                alt_text = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    if "=" in attr:
                        key, value = attr.split("=", 1)
                        picture_info[key.strip()] = value.strip()
                    else:
                        # If no '=', it's part of the alt text
                        if alt_text:
                            alt_text += ", " + attr.strip()
                        else:
                            alt_text = attr.strip()
                picture_info["alt"] = alt_text
```

Wait, if `attributes[0]` is empty, and `attributes[1]` is "something", then `alt_text` will be "something".
If `attributes[0]` is "Alt", and `attributes[1]` is "something", then `alt_text` will be "Alt, something".
This seems correct.

One detail: what if `attributes` is `['']`?
`alt_text` = `""`.
Loop doesn't run.
`picture_info["alt"]` = `""`. Correct.

What if `attributes` is `[' Alt ', '  ']`?
`alt_text` = `Alt`.
`attr` = `  `. `"=" in attr` is False.
`alt_text` = `Alt, `.
`picture_info["alt"]` = `Alt, `.
Is this a problem? Maybe. But the user's alt text has commas, so it's probably acceptable.

Let's verify the `split("=", 1)` to be safe.

Actually, I can simplify the logic a bit:
```python
            if attributes:
                alt_text = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    if "=" in attr:
                        key, value = attr.split("=", 1)
                        picture_info[key.strip()] = value.strip()
                    else:
                        # Continue alt text
                        alt_text = f"{alt_text}, {attr.strip()}" if alt_text else attr.strip()
                picture_info["alt"] = alt_text
```

Wait, there's a potential issue: if `attributes[0]` is `width=100`.
Current code: `alt` = `width=100`.
My code: `alt_text` = `width=100`. `picture_info["alt"]` = `width=100`.
Matches current behavior.

Wait, if `attributes` = `['Alt text', 'width=100', 'extra piece']`.
Current code crashes.
My code: `alt` = `Alt text`, `width` = `100`, `alt` becomes `Alt text, extra piece`? No, `picture_info["alt"]` is set at the end.
So `alt_text` becomes `Alt text`, then `width` is set, then `alt_text` becomes `Alt text, extra piece`.
Then `picture_info["alt"]` is set to `Alt text, extra piece`.
This is consistent.

Let's apply the fix.

{
  "filepath": "docling/backend/asciidoc_backend.py",
  "new_string": "            if attributes:\n                alt_text = attributes[0].strip() if attributes[0] else \"\"\n                for attr in attributes[1:]:\n                    if \"=\" in attr:\n                        key, value = attr.split(\"=\", 1)\n                        picture_info[key.strip()] = value.strip()\n                    else:\n                        alt_text = f\"{alt_text}, {attr.strip()}\" if alt_text else attr.strip()\n                picture_info[\"alt\"] = alt_text",
  "old_string": "            if attributes:\n                picture_info[\"alt\"] = attributes[0].strip() if attributes[0] else \"\"\n                for attr in attributes[1:]:\n                    key, value = attr.split(\"=\")\n                    picture_info[key.strip()] = value.strip()"
}

{
  "status": "ok",
  "filepath": "docling/backend/asciidoc_backend.py",
  "occurrences": 1,
  "strategy": "exact",
  "diff": "--- a/docling/backend/asciidoc_backend.py\n+++ b/docling/backend/asciidoc_backend.py\n@@ -414,10 +414,14 @@\n \n             # Extract optional attributes (alt text, width, height, alignment)\n             if attributes:\n-                picture_info[\"alt\"] = attributes[0].strip() if attributes[0] else \"\"\n+                alt_text = attributes[0].strip() if attributes[0] else \"\"\n                 for attr in attributes[1:]:\n-                    key, value = attr.split(\"=\")\n-                    picture_info[key.strip()] = value.strip()\n+                    if \"=\" in attr:\n+                        key, value = attr.split(\"=\", 1)\n+                        picture_info[key.strip()] = value.strip()\n+                    else:\n+                        alt_text = f\"{alt_text}, {attr.strip()}\" if alt_text else attr.strip()\n+                picture_info[\"alt\"] = alt_text\n \n             return picture_info\n \n",
  "is_truncated": false
}

Now let's verify the fix with the reproduction script.

{
  "command": "python3 - <<'PY'\nfrom docling.document_converter import DocumentConverter\nfrom docling.datamodel.base_models import InputFormat\nfrom pathlib import Path\nimport tempfile\nimport os\n\n# Minimal .adoc file with commas in alt text\ncontent = \"\"\"= Test Document\n\nimage::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]\n  \"\"\"\n\nwith tempfile.NamedTemporaryFile(suffix=\".adoc\", mode=\"w\", delete=False) as f:\n    f.write(content)\n    tmp_path = Path(f.name)\n\ntry:\n    converter = DocumentConverter(allowed_formats=[InputFormat.ASCIIDOC])\n    result = list(converter.convert_all(source=[tmp_path], raises_on_error=False))\n    print(f\"Status: {result[0].status}\")\n    print(f\"Errors: {result[0].errors}\")\n    # Let's also check if the result contains the correct info\n    # We need to access the internal representation. \n    # DocumentConverter.convert_all returns a list of ConversionResult.\n    # result[0].document should have the parsed content.\n    # Since we are just testing the backend, maybe we can test _parse_picture directly.\n    from docling.backend.asciidoc_backend import AsciiDocBackend\n    line = \"image::images/screenshot.png[A screenshot showing a dialog box, containing text fields, buttons, and validation errors, width=604, height=422]\"\n    res = AsciiDocBackend._parse_picture(line)\n    print(f\"Parsed: {res}\")\nfinally:\n    if tmp_path.exists():\n        os.remove(tmp_path)\nPY\n"
}

{
  "status": "ok",
  "stdout": "Status: success\nErrors: []\nParsed: {'type': 'picture', 'uri': 'images/screenshot.png', 'width': '604', 'height': '422', 'alt': 'A screenshot showing a dialog box, containing text fields, buttons, and validation errors'}\n",
  "stderr": "",
  "exit_code": 0
}

The fix works! The status is `success`, and the parsed information is exactly what we expect.

Now let's check if it breaks any existing tests.
`tests/test_backend_asciidoc.py` seems relevant.

{
  "command": "pytest tests/test_backend_asciidoc.py -q --tb=short --no-header"
}

{
  "status": "ok",
  "stdout": "..                                                                       [100%]\n2 passed in 2.15s\n",
  "stderr": "",
  "exit_code": 0
}

Existing tests passed.

Let's double check for parallel implementations.
`docling/backend/asciidoc_backend.py` seems to be the only AsciiDoc backend.
The search for `_parse_picture` showed:
`./docling/backend/asciidoc_backend.py:204:                item = self._parse_picture(line)`
`./docling/backend/asciidoc_backend.py:404:    def _parse_picture(line):`
`./tests/test_backend_asciidoc.py:25:def test_parse_picture():`

Wait, is there any other place where picture macros are parsed in AsciiDoc?
I searched for `_parse_picture` and it's only in `asciidoc_backend.py`.

Let's check if there are other methods that might have similar splitting issues.
I'll search for `.split(",")` in `docling/backend/asciidoc_backend.py`.

{
  "command": "grep -n '\\.split(\",\")' docling/backend/asciidoc_backend.py"
}

{
  "status": "ok",
  "stdout": "412:            attributes = mtch.group(2).split(\",\")\n",
  "stderr": "",
  "exit_code": 0
}

Only one place.

Wait, I should also check for `split(",")` with optional whitespace or other variations.
Actually, searching for `.split(` might be better.

{
  "command": "grep -n '\\.split(' docling/backend/asciidoc_backend.py"
}

{
  "status": "ok",
  "stdout": "38:                self.lines = text_stream.split(\"\\n\")\n365:        return [cell.strip() for cell in line.split(\"|\") if cell.strip()]\n412:            attributes = mtch.group(2).split(\",\")\n420:                        key, value = attr.split(\"=\", 1)\n",
  "stderr": "",
  "exit_code": 0
}

The only suspicious one was line 412, which we fixed.

Let's consider edge cases for `_parse_picture`.
1. Empty brackets: `image::path[]`
   `mtch.group(2)` is `""`. `attributes` is `['']`.
   `alt_text` = `""`.
   `attributes[1:]` is empty.
   `picture_info["alt"]` = `""`.
   Result: `{"type": "picture", "uri": "path", "alt": ""}`. Correct.

2. No brackets: `image::path`
   `mtch = re.match(r"^image::(.+)\[(.*)\]$", line)`
   If line is `image::path`, then `mtch` is `None`.
   Result: `{"type": "picture", "uri": "image::path"}`.
   Wait, if the line is `image::path`, `re.match` fails because of `\[(.*)\]$`.
   The return at the end is `return {"type": "picture", "uri": line}`.
   Wait, `line` contains `image::`. This might be wrong, but it's existing behavior and not what we are fixing.
   Actually, if I check the code:
   ```python
   mtch = re.match(r"^image::(.+)\[(.*)\]$", line)
   if mtch:
       ...
   return {"type": "picture", "uri": line}
   ```
   If `line` is `image::path`, it returns `{"type": "picture", "uri": "image::path"}`.
   Is this correct? Probably not, it should probably be stripped of `image::`.
   But again, the task is to fix the crash with commas in alt text.

3. Leading comma: `image::path[,width=100]`
   `mtch.group(2)` is `,width=100`.
   `attributes` = `['', 'width=100']`.
   `alt_text` = `""`.
   Loop `attr = 'width=100'`. `"=" in attr` is True.
   `key="width", value="100"`. `picture_info["width"] = "100"`.
   `picture_info["alt"]` = `""`.
   Result: `{"type": "picture", "uri": "path", "width": "100", "alt": ""}`. Correct.

4. Alt text with `=`, but not a KV pair: `image::path[Alt text = imagine, width=100]`
   `attributes` = `['Alt text = imagine', ' width=100']`.
   `alt_text` = `Alt text = imagine`.
   Loop `attr = ' width=100'`. `key="width", value="100"`.
   `picture_info["alt"]` = `Alt text = imagine`.
   Correct. Wait, what if `attributes[0]` contains `=`?
   If `attributes[0]` is `alt=something`, then `alt_text` is `alt=something`.
   Wait, the current code does:
   `picture_info["alt"] = attributes[0].strip() if attributes[0] else ""`
   So it doesn't matter if it has `=`, it's still treated as alt text.

Wait, what if:
`image::path[width=100, height=200]`
The user probably expects `width` to be 100 and `height` to be 200, and `alt` to be empty.
But the code does:
`alt_text` = `width=100`
`height` = `200`
`alt` = `width=100`
This is because the first attribute is always alt text in AsciiDoc if not preceded by a comma.
To omit alt text, you MUST use `[,width=100, height=200]`.

So my fix is perfectly aligned with existing behavior.

Final check on the code:
```python
            if attributes:
                alt_text = attributes[0].strip() if attributes[0] else ""
                for attr in attributes[1:]:
                    if "=" in attr:
                        key, value = attr.split("=", 1)
                        picture_info[key.strip()] = value.strip()
                    else:
                        alt_text = f"{alt_text}, {attr.strip()}" if alt_text else attr.strip()
                picture_info["alt"] = alt_text
```
This looks robust.

One last check: the problem description mentioned `RuntimeError: Pipeline SimplePipeline failed, even with raises_on_error=False the document is marked as FAILURE`.
This happened because of the `ValueError` from the unpacking. My fix removes this `ValueError`.

I'll check if there are any other files I should have looked at.
The problem statement says `AsciiDocBackend._parse_picture() crashes`. I've fixed it there.
The `DocumentConverter` just calls the backend.

I am confident in the solution.

{
  "command": "git status --short && git diff"
}

{
  "status": "ok",
  "stdout": " M docling/backend/asciidoc_backend.py\ndiff --git a/docling/backend/asciidoc_backend.py b/docling/backend/asciidoc_backend.py\nindex c6a0d18..3efe71b 100644\n--- a/docling/backend/asciidoc_backend.py\n+++ b/docling/backend/asciidoc_backend.py\n@@ -414,10 +414,14 @@ class AsciiDocBackend(DeclarativeDocumentBackend):\n \n             # Extract optional attributes (alt text, width, height, alignment)\n             if attributes:\n-                picture_info[\"alt\"] = attributes[0].strip() if attributes[0] else \"\"\n+                alt_text = attributes[0].strip() if attributes[0] else \"\"\n                 for attr in attributes[1:]:\n-                    key, value = attr.split(\"=\")\n-                    picture_info[key.strip()] = value.strip()\n+                    if \"=\" in attr:\n+                        key, value = attr.split(\"=\", 1)\n+                        picture_info[key.strip()] = value.strip()\n+                    else:\n+                        alt_text = f\"{alt_text}, {attr.strip()}\" if alt_text else attr.strip()\n+                picture_info[\"alt\"] = alt_text\n \n             return picture_info\n \n",
  "stderr": "",
  "exit_code": 0
}

Everything looks clean. No untracked files.

{
  "status": "ok",
  "patch_size": 1072,
  "files_changed": 1
}

The fix is submitted.

Fixed the `ValueError` in `AsciiDocBackend._parse_picture` by updating the attribute parsing logic to correctly handle alt text containing commas. Now, attributes without an equals sign are correctly appended to the alt text instead of causing an unpacking crash.