[yavuzmeteafsar]

What does this change?

Fixes #1204. RTF → TXT now takes LibreOffice's direct edge, so code copied from an IDE keeps its text, indentation and blank lines.

This is a change from the plan in the issue. Marking Pandoc's rtf → md edge DirectOnly moved the route to the next built-in one, RTF → HWPX → TXT (about 32 with the priority penalties, against 34 for LibreOffice; through Markdown it was about 29). That route has no backticks, but it puts the whole file on one line:

import java.io.BufferedReader;class FileTask implements Runnable {    private String fileName;    public void run() { …

So Pandoc is untouched, and instead LibreOffice adds rtf → txt at Chosen (10) as a DirectOnly edge:

• RTF → TXT goes through LibreOffice when it is installed. Without LibreOffice nothing changes, so it never falls through to the one-line route.
• DirectOnly keeps it a route of its own, so it doesn't become a cheap hop towards other formats (RTF → EPUB, for example).
• RTF → MD still goes straight through Pandoc.

The HWPX route losing the line breaks looks like a bug of its own, so I can open a separate issue for it if you'd like.

Type of change

• Bug fix
• New feature or improvement
• New format or engine
• Translation
• Documentation
• Build, CI or dependencies

How was it tested?

On macOS 27.0.1 with Pandoc and LibreOffice installed:

• dotnet format --verify-no-changes
• dotnet test: Filee.Core.Tests (1216 passed, 6 skipped), plus the route, RTF → TXT, Pandoc and Markdown tests in Filee.Engines.Tests (109 passed, 37 skipped). The one failure there, FolderIso632Tests.Archive_to_iso_uses_a_direct_archive_route_without_enabling_unrelated_inputs, fails the same way on main without this commit: 7-Zip isn't installed here, so Plan("zip", "iso") is null.
• Tried it with the CLI on the IDE sample: before the change, RTF → TXT gave backticks and RTF → HWPX → TXT gave one line; after it, the same file comes out clean.

New tests:

• LibreOfficeRouteTests.Rtf_goes_to_txt_through_libreoffice: RTF → TXT is one LibreOffice step, RTF → MD is still Pandoc, and RTF → EPUB doesn't go through TXT.
• RtfToTextTests.Code_copied_from_an_IDE_keeps_its_text: a run-heavy RTF like the IDE example (a colour run per token and an italic out) comes out with no backticks and with its blank lines, indentation, "\n" and "\\W+". It is skipped without LibreOffice.

One more note: for text in a proportional font (not code from an IDE), LibreOffice adds a U+2006 before each space in a run of spaces. It does this on purpose to match Word's spacing (tdf#123703). The IDE case isn't affected, and I left it out of this PR.

Checklist

• New UI strings are in all src/Filee.App/Assets/i18n/*.json files
• New third-party code or binaries are listed in THIRD-PARTY-NOTICES.md
• The PR does one thing (unrelated changes go in a separate PR)

[yavuzmeteafsar]

CI caught something I missed: Every_edge_has_a_filter_of_its_application keeps LibreOffice's edges at 25 or more, so built-in engines stay first, and this PR's rtf → txt edge at Chosen (10) breaks that rule. Sorry about that.

I looked into why the built-in HWPX route loses the lines, and it isn't Filee: the HWPX the writer makes from the RTF is right (13 <hp:lineBreak/>, blank lines and indentation all there), but Unhwp drops <hp:lineBreak/> when it turns the document into text or Markdown. Filee's Unhwp 0.13.0 does it, and so does the latest 0.23.1.

So there are a few ways to go, and I'd like your call:

1. Keep this PR and allow RTF → TXT as an exception in that test, next to presentations → PDF.
2. Go back to the plan in [Bug]: RTF → TXT goes through Markdown and breaks code (backticks, indentation, blank lines) #1204 (DirectOnly on Pandoc's rtf → md) and report the line breaks to Unhwp. RTF → TXT would then go through the HWPX route, which stays one line until Unhwp fixes it, and is right after that, with or without LibreOffice.
3. Something else you'd prefer.

I'll update the PR once you've picked one.

[KnifeLemon]

Thanks for digging into this, @yavuzmeteafsar, and for tracking the one-line output down to Unhwp.

Let's go with option 1: keep this PR and allow RTF → TXT as an exception in Every_edge_has_a_filter_of_its_application.

The rule in that test is there so routes Filee can run by itself win. RTF has none: DocumentReaders reads RTF only through Pandoc. So every other RTF → TXT route already depends on an optional engine, and LibreOffice is the one that keeps the text. Going back to the #1204 plan would ship the one-line result until Unhwp changes.

What's needed:

1. In tests/Filee.Engines.Tests/LibreOfficeFormatTests.cs, exclude only rtf → txt next to the presentations → PDF exception, and add a line to the comment above it, e.g. "RTF → TXT: RTF has no built-in reader, and every other route reads it through Pandoc ([Bug]: RTF → TXT goes through Markdown and breaks code (backticks, indentation, blank lines) #1204)."
2. Nothing else needs to change. The DirectOnly edge and both new tests look right.

About the HWPX line breaks: please open a separate Filee issue with what you found (<hp:lineBreak/> dropped by Unhwp in HWPX → TXT/MD, 0.13.0 and 0.23.1), so we can decide there how to handle it. The U+2006 spacing can stay out of this PR as you suggested.

[yavuzmeteafsar]

Thanks! Done in the second commit: rtf → txt sits next to the presentations → PDF exception, with a line in the comment above it. I'll open the separate Unhwp line-break issue next.

[KnifeLemon]

Thanks, @yavuzmeteafsar, that's exactly it.

• The exception in Every_edge_has_a_filter_of_its_application is as narrow as it should be, and the comment says why.
• DirectOnly keeps RTF → TXT from becoming a hop on the way to other formats, and Rtf_goes_to_txt_through_libreoffice pins that down (rtf → md still goes through Pandoc).
• The IDE sample in RtfToTextTests covers the three things #1204 was about: backticks, indentation and blank lines.

And thanks for filing the Unhwp line breaks separately as #1416. Merging now!