-
Notifications
You must be signed in to change notification settings - Fork 16
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
Test v3.14 roundtrip #34
Conversation
Could it be the new {
"SceneInfo": {
"backgroundVisible": {
"timestamp": "0:0",
"value": 1
},
"currentLayer": {
"timestamp": "0:0",
"value": "0:0"
},
"paperSize": {
"first": 1404,
"second": 1872
},
"rootDocumentVisible": {
"timestamp": "0:0",
"value": 1
}
}
} (this is from one of my file using the debug env var of the remarkable software) In your 3.14.4 file, it is Hope it can help :) |
Me again :) I just had time to run the pipeline/tests with the commit I mentioned and another one, and it appears to fix the pipeline, see here Seb-sti1#1 (of course, I did not deactivate the pipeline to publish on PyPI, so the corresponding pipelines fail). Regarding the two commits: The first one (Seb-sti1@9505d1d) is the addition of paperSize in the SceneInfo classOn the files that had excess bytes, they were
The first implementation I tried was with the code below as it seemed to be closer to a simple value but given the existence of what appears to be a size I changed it and used def read_two_int(self, index: int) -> tuple[int, int]:
"""Read a tagged two 4-byte int."""
self.data.read_tag(index, TagType.Length4)
first = self.data.read_uint32()
second = self.data.read_uint32()
return first, second
def read_two_int_optional(
self, index: int, default: tp.Optional[float] = None
) -> tp.Optional[tuple[int, int]]:
"""Read a tagged two 4-byte int."""
return self._read_optional(self.read_two_int, index, default) The second one (Seb-sti1@ecd56a0) makes the
|
This allows for round-tripping of data where blocks contain new tagged values which have not been added to the parsing code.
Currently this is xfailing for `Color_and_tool_v3.14.4.rm` because the parser is not updated yet. When it is, the xfail mark should be removed.
63e9baa
to
0287369
Compare
I think you're right that those are the parts that are not parsed, but given we have the It also adds another test, which checks that all the blocks were actually parsed correctly. One of this is |
No description provided.