Disclaimer: I’m aware that I’m trying to do something really odd… but… hey. I want to get a command line script to do some color switching on .xd files (convert from 2 themes), since XD doesn’t allow for that yet.
My naive plan was simple: unzip the xd, do some bash script surgery on the files, zip again and success! However, I can’t unzip the xd file and zip it without getting the error 86. There’s something I’m missing on the way I’m doing things. I tried to control the file orders, what got compressed and whatnot, but I’m missing some fundamental detail
Bellow are the unzip -vl of the 2 files, where I just unzipped and zipped. The first one opens in XD, the other gives the error 86
Not sure if others will provide a more direct answer to your question, but I do want to give you a friendly heads up that modifying/creating files directly like this is not supported nor recommended. Adobe XD doesn’t document its file spec, which can change without warning. Please be aware of the inherent likely risk.
I did that, Dennis, file by file and respecting the order. Only difference I could spot was the Defl:S vs Defl:F on the method reported by unzip - and I couldn’t find out what that thing is…
Even looking at it file by file, the size is identical (apart a 2 byte difference in the .json files)…
There’s something else going on here that I’m missing
It’s important. Defl:S and Defl:F are different methods (as i remember S is stored, which means no-compression at all), so make same methods and test it again
Please don’t try this. We strongly strongly discourage it. XD’s file format is delicate, undocumented, and changes almost every release in ways you could easily be unaware of.
I know it may feel temptingly convenient to try hacking around in the internals to get around limitations of what you can do in XD today (with or without plugins), but – there are many things that can go wrong, and they are often very subtle. E.g. you’ll think your modifications worked fine, but a month later you try to edit part of the file in XD and XD crashes or deletes chunks of your content without warning. By then you have many hours of work invested in a corrupted document which you may have to recreate from scratch to recover from.
Error logs from manually-modified files like this also add noise to the telemetry data we use to assess XD’s quality, potentially leading to engineering effort being spent searching for XD bugs that don’t really exist – cycles we could otherwise spend fixing real bugs or building new features.
For those reasons, we at Adobe can’t offer any assistance or answer any questions regarding this; and we actively avoid promoting or discussing any tools that try to use techniques like this.
Don’t you think being able to see how this stuff works is good for education purposes? Many developers started into development by looking at the source code of web pages.
I don’t think so–how the document data is stored is really just a trivial engineering decision. Not much to learn from it, since the only official way to access document content is through the API.
And it’s probably an exercise in frustration, since there’s probably a lot in there you can’t get through the API. Though I guess one could try to vote up new API access.
This is the point he’s making. He has a problem that a plugin script will solve but the API doesn’t exist yet. Accessing and modifying the document data would solve that “with risks”. The same could be said of the veterans that started making their own motorcycles. This sort of gets into right to repair.
No right to repair and you have to ask if what you purchased is your own.
Some right to repair but you void your warranty is another. Yes I’ve been reading about that recently lol.
Sure, he can hack on the file all he wants since he “owns” it (agree entirely about “right to repair”), but you can’t expect a “warrantee” (read: Adobe support) to stay in effect if you’re hacking the machine internals.
And he’s only making headaches for himself as things he changes break XD in subtle ways that are impossible to fix or even predict.
Just a follow up on this. Even though I would absolutely not expect any kind of “warranteed” approach - as I believe was clear from the beginning - I got to the conclusion that doing this via a plugin is a much better approach, and that’s what I’ll be doing
