-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delta lists appear to be missing a clear indication of when a list ends. #26
Comments
Deltas are just a format your can use to express rich text of which there are multiple ways one can use to express nested lists. If you are looking for info on how Quill choses to express it take a look at https://quilljs.com/docs/delta/#line-formatting and play around with the interactive playground to try things out. |
I understand what the delta is. I'm just saying, read the delta. Please explain to me how you can logically determine one list from the other. You can't. The end result when rendered in QuillJS is ALMOST working, but even it has its problems. There is no logical conclusion you can make reading the delta of where one list ends and the other starts. And if you can't make that determination by merely reading the data, how do you expect to logically code for that? You can't. I'm also not arguing Nested lists. I got them working just fine. The indent's gave me all the information i needed to cycle through numbering strategies etc. But there is no way I can know definitively when i've went from one list to another. So back end .. i don't know when to "new List()" #2 ... i have to assume everything in list 2 goes with list 1. I think you need to look at this deeper and don't just dismiss it because you think you're right. Because you aren't. and until you can prove it to me otherwise. That is my stance .. and i'm going to keep reporting this problem. |
Something else to consider ... this problem i'm citing here, might also have something to do with the other problem i posted: slab/quill#2221. I think that QuillJS might make too many assumptions with regards to the lists. And it would have to make those assumptions, because there is no alternative, there is missing delta data critical to knowing that the list has ended. I will admit that I haven't looked at the code for QuillJS to know if they are doing what I assume they are doing, but if they are, then it isn't concrete enough to make extensible to other renderers. |
The statements you are making contain multiple false assumptions and/or misunderstandings that would benefit from re-reading the docs I have already linked. |
There were indeed some bad assumptions that I was making. I have resolved the issues. I'm sorry if I was a being a bit obtuse, but I was running on like 72 hours straight with very little sleep. I've since had time to reflect and reread your documentation and I finally arrived at an understanding and now have it working perfectly. Thank you ! |
Can you explain how you resolved this issue? I am also having the same issue while converting Delta to HTML manually. |
Please consider the following JSON/Delta provided.
{ "ops": [ { "insert": "List 1 - Item 1" }, { "attributes": { "list": "ordered" }, "insert": "\n" }, { "insert": "List 1 - Item 2" }, { "attributes": { "list": "ordered" }, "insert": "\n" }, { "insert": "\nSome text between lists ...\n\nList 2 - Item 1" }, { "attributes": { "list": "ordered" }, "insert": "\n" }, { "insert": "List 2 - Item 2" }, { "attributes": { "list": "ordered" }, "insert": "\n" }, { "insert": "\nSome final text ...\n" } ] }
I am writing conversion code that turns this delta into an identical WPF FlowDocument. I have no way to discern where 1 list ends and the other begins. Perhaps I am just not considering something, but from an interpretative stand-point (WPF FlowDocument specifically, and it's use of Nested Lists) - This is one thing I am struggling to get past.
Any thoughts on this?
The text was updated successfully, but these errors were encountered: