https://bugs.kde.org/show_bug.cgi?id=443767
--- Comment #5 from Ron <[email protected]> --- > The proper visual apprearence of the vertical text layout are already > documented by Unicode Consortium and W3C, as well as other official > standards. Which is nice, but if no player implements support for that in subtitles, it's not of much practical use to us. Can you point to a non-browser player that supports WebVTT vertical cues? (or even a browser based one?). Of the ones I'm seeing that support any WebVTT cue properties at all, none implement the vertical property. Right now, ASS subtitles are basically the sweet spot in the venn diagram for feature richness and player support. They aren't a perfect solution for every use case, but they let you control more things, more portably in more players on more platforms *today*. It doesn't matter what we support if nothing that people try to play it in will make it look like it did when they edited it. We can't lead the players in this or force them to implement it, we need to make things that they *can* play. > If Qt have no support for vertical text, or there's something difficult to > make use of, > you have to write something new or find out a library that could help. We don't *have* to do anything. But kdenlive uses Qt for its UI, so that's one more thing we're constrained by. Another is that few fonts have metrics for vertical text, so even if you did try to lay them out in that direction, the result will still be indistinguishable from sticking a newline between each character. And no matter what we do there, it still doesn't make players support this for subtitles. > Anyway, this is not only "graphic art", but also "text support". Even if > Adobe software can do this for titles. > If you got this text support, you'll pave the way do so for graphic art. You're missing my point, adobe isn't doing this for *subtitles* either. And they are also individually placing individual characters in their more 'advanced' modes of text handling, not laying out text 'as text' according to the metrics of the font designer. Which totally falls in a heap in the case of subtitles, where the player and/or its user can totally override your choice of font and font size and colour and position, and just about everything else. This puts what adobe is doing in the realm is graphic art, and is something in a long list of things that it would be nice for a future *title* tool to be more powerful at enabling simply. It's just never going to be possible with *subtitles*, sanely or at all, until there's actually a widely supported and implemented mechanism for that. And I'm not seeing that on any visible horizon right now. "Titles" and subtitles are two quite different things. With different uses and and strengths and weaknesses. They aren't interchangeable for every use case just because they both can include 'text'. So if you want to talk about things that it might be nice for a future *title* tool to do, that's probably a good discussion to have in the open on the user forum https://discuss.kde.org/tag/kdenlive/l/latest to refine a sense of exactly what people might really want from it and have a real use for, to guide its design. That's fertile ground to grow feature requests in. But if you want to insist we do this with *subtitles*, then for the currently foreseeable future it's probably a "can't fix" problem. Because it's not about whether kdenlive "supports it", it's about whether any player can play it. -- You are receiving this mail because: You are watching all bug changes.
