PyQt6: QSvgWidget does not render when loading a QByteArray instead of a file
-
@JonB many thanks for your links.
My own search leaded me to similar answers that where written for Pyside2 or PyQt5 but none of them was really relevant for my case.I can now go further and make my SVG produced dynamically by a refresh function. I will see if loading another svg will trigger the rendering. Yous links could be interesting if rendering does not occur in that case.
Concerning utf-8, no one should use any other encoding now for python scripts, svg or any text file unless having a very good reason to use another encoding. With windows API, utf16-le is also common but it's a niche.
-
@JonB many thanks for your links.
My own search leaded me to similar answers that where written for Pyside2 or PyQt5 but none of them was really relevant for my case.I can now go further and make my SVG produced dynamically by a refresh function. I will see if loading another svg will trigger the rendering. Yous links could be interesting if rendering does not occur in that case.
Concerning utf-8, no one should use any other encoding now for python scripts, svg or any text file unless having a very good reason to use another encoding. With windows API, utf16-le is also common but it's a niche.
-
@ErwanM
Technically this has nothing to do with PySide, PyQt or Python. I imagine you would get same problem if you sent it from C++ or wherever with preceding whitespace, or if you edited your external file and put a blank line at the very start.@JonB the link to python comes from the here string syntax: the string start just after the triple quote and not at the next line.
In others language like perl, the here string start at the next line to preserve the first line indent.C++ 11 introduced a here string like construction and, again, the raw string start at the next line.
So this error is in part due to the language syntax for here string.
-
Well if you don't know whether your language happens to put in or not put a linefeed in whatever string literal construct you choose to use that is a problem. But the error here is the due to the parsing of the XML requiring there be no leading whitespace, that's all I'm saying.
@ErwanM said in PyQt6: QSvgWidget does not render when loading a QByteArray instead of a file:
C++ 11 introduced a here string like construction and, again, the raw string start at the next line.
Pardon/really? Not to the best of my knowledge, but I may be at fault. Which construct are you talking about (example please) and where do you claim " the raw string start at the next line" is the case? The C++ literals I can think of (e.g.
R"(...)") would not only "start at the next line", the initial line where the string literal opener is placed would "count" towards the string content. Perl or Linux shells have the "here document", and that indeed does not count the start line, only the following line below, but that's not C++. -
Well if you don't know whether your language happens to put in or not put a linefeed in whatever string literal construct you choose to use that is a problem. But the error here is the due to the parsing of the XML requiring there be no leading whitespace, that's all I'm saying.
@ErwanM said in PyQt6: QSvgWidget does not render when loading a QByteArray instead of a file:
C++ 11 introduced a here string like construction and, again, the raw string start at the next line.
Pardon/really? Not to the best of my knowledge, but I may be at fault. Which construct are you talking about (example please) and where do you claim " the raw string start at the next line" is the case? The C++ literals I can think of (e.g.
R"(...)") would not only "start at the next line", the initial line where the string literal opener is placed would "count" towards the string content. Perl or Linux shells have the "here document", and that indeed does not count the start line, only the following line below, but that's not C++.@JonB as many people do, i don't make use of a single language but many of them from several assembly languages to high level ones like perl, php, javascript, SQL or even bash/cmd.
When programmers have to switch between many languages, any particularity represent a potential trap. Python here string syntax is one of them because it's not the common way to do it.
-
@JonB as many people do, i don't make use of a single language but many of them from several assembly languages to high level ones like perl, php, javascript, SQL or even bash/cmd.
When programmers have to switch between many languages, any particularity represent a potential trap. Python here string syntax is one of them because it's not the common way to do it.
@ErwanM
I asked you a simple question. You stated:C++ 11 introduced a here string like construction and, again, the raw string start at the next line.
And I said I did not think so. Could you kindly provide an example of whatever you mean by "a here string like construction" in C++ which has "the raw string start at the next line"? Because the only think I can think you might mean is the
R"(...)"construction and as I said that does not "start on the next line", it started immediately after the openingR"(, just as is does for the Python""".This is not a criticism of you, and of course your swapping between multiple languages (just as I do) is an understandable source of confusion. It is merely an attempt to clarify or put the record straight for other readers of your earlier statement. We like to keep things accurate on this site :)
-
@ErwanM
I asked you a simple question. You stated:C++ 11 introduced a here string like construction and, again, the raw string start at the next line.
And I said I did not think so. Could you kindly provide an example of whatever you mean by "a here string like construction" in C++ which has "the raw string start at the next line"? Because the only think I can think you might mean is the
R"(...)"construction and as I said that does not "start on the next line", it started immediately after the openingR"(, just as is does for the Python""".This is not a criticism of you, and of course your swapping between multiple languages (just as I do) is an understandable source of confusion. It is merely an attempt to clarify or put the record straight for other readers of your earlier statement. We like to keep things accurate on this site :)
@JonB yes, you're right. C++ raw string literals start just after the first delimiter.
Coupled with the fact that end delimiter can be on the same line as content, this makes two traps instead of one.
These characteristics allow the construction of a one line raw string but this is not the common case i think.
In the examples i found on Stack overflow, i've seen xml files, starting at the next line after the start delimiter.
This is just a banana peel that python and C++ developers have left to make developer slip away.
-
@JonB yes, you're right. C++ raw string literals start just after the first delimiter.
Coupled with the fact that end delimiter can be on the same line as content, this makes two traps instead of one.
These characteristics allow the construction of a one line raw string but this is not the common case i think.
In the examples i found on Stack overflow, i've seen xml files, starting at the next line after the start delimiter.
This is just a banana peel that python and C++ developers have left to make developer slip away.
@ErwanM said in PyQt6: QSvgWidget does not render when loading a QByteArray instead of a file:
In the examples i found on Stack overflow, i've seen xml files, starting at the next line after the start delimiter.
That would be interesting. Any links? Because as we have discovered if they start with the
<?xmldeclaration that must be in very first character position, no whitespace/newline character before. OTOH if they do not have this declaration, e.g. they just start with<SomeNode>, then per the XML spec that can be preceded by whitespace (e.g. newline), it is only the<?xmlwhich has to appear from first character spot, maybe that is what you saw? -
In this thread, most of people are using raw string literal as i do with line breaks around the raw string: https://stackoverflow.com/questions/1135841/how-to-write-a-multi-line-string-literal
@ErwanM
Yes, the ones there using theR"(-type construct are shown having leading & trailing newlines which will be in the resulting string. One guy does even sayAll the spaces and indentation and the newlines in the string are preserved.
That's up to them for their examples where it doesn't matter. In your case of
<?xmlwe simply cannot afford that.The one which starts
std::string index_html=R"html( <!DOCTYPE html>would have a newline before the
<!DOCTYPE html>, but maybe that is allowed, unlike for<?xml. Or maybe it isn't allowed either and they didn't check!Anyway, there we are, that's just how it is.
