@rozPierog when you submit a PR that resolves an issue, please use the correct keywords like "fixes" or "resolves" according to https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests to autoclose issues when your PR gets merged so we keep the issue page tidy.

@damontecres I see that Markdown library that you are using is also exposing buildMarkdownAnnotatedString
mikepenz/multiplatform-markdown-renderer#246 (comment) that will retain maxLines and still render markdown while being more true to the Jellyfin web than my proposed HTML rendering. I'll implement that and check if it works fine

I see that Markdown library that you are using is also exposing buildMarkdownAnnotatedString
mikepenz/multiplatform-markdown-renderer#246 (comment) that will retain maxLines and still render markdown

Nice, that has potential. I am concerned about parsing the markdown in compose code though since that would be on the main thread. At the very least use remember.

But it might be good to parse the content into the ASTNode (MarkdownParser.buildMarkdownTreeFromString) separately or even build the AnnotatedString. But it looks like like building the AnnotatedString doeds need composable code to get font sizes and whatnot.

Take a look at the BaseItemUi class which pre-computes an AnnotatedString for the "quick details".

I'm worried that this won't be as easy as it look at the start. We cannot build markdown annotated strings outside of the multiplatform-markdown-renderer context, as it is depended on LocalMarkdownColors LocalMarkdownStyles etc.

And even if I create reimplementation of the Markdown component then I would have control over paragraph rendering, but given that Markdown can have multiple paragraphs, and maxLines would apply to them separately it seems much less useful.

I think best approach would be to

1. strip markdown from the "preview" inside OverviewText/Homepage
2. Render overview inside Markdown component in ItemDetailsDialog, as we don't need to clamp it there

That's additional string manipulation, possibly it could be precomputed into overviewBaseText or something to save on performance during browsing but I want to first hear your opinion on this @damontecres

I think I'm overthinking this and trying to pre-optimize. I think most overview texts will be plaintext and overhead of the markdown parsing plaintext should be tiny.

So, @rozPierog I think you can implement it with the Text composable with like remember(overview) { overview.buildMarkdownAnnotatedString(...) } as you suggested.

And if it looks good, I'll run the profiler with some sample overviews and see if there's any significant performance change.

I think it got lost in the noise in my previous comment, but I cannot use buildMarkdowAnnotatedString outside Markdown component body as it requires LocalMarkdownStyle and LocalMarkdownColors. That's why I proposed second solution with only rendering Markdown in the preview Modal while keeping plain text in other places @damontecres

cannot use buildMarkdowAnnotatedString outside Markdown component body [...] I proposed second solution with only rendering Markdown in the preview Modal while keeping plain text in other places

I poked around more in the library and its docs and it would be very complicated to use buildMarkdowAnnotatedString.

So I think your proposal is an easy solution that solves most of the problem.

@damontecres I added a stripping util, added tests around it, and moved the ItemDetailsDialogInfo overview rendering to Markdown component. Could you take a look if that makes sense to you?