View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014861 | Scribus | Internal | public | 2017-06-12 08:33 | 2025-01-05 11:08 |
Reporter | kervala | Assigned To | |||
Priority | low | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Platform | Windows | OS | 10 (64 bits) | OS Version | 10.0.14393 |
Product Version | 1.5.3 | ||||
Summary | 0014861: Keep same ItemID when saving | ||||
Description | Hi there, I like to compare several versions of SLA files to see changes and fix them (for example to keep synchronization of 2 variants of a SLA), unfortunately each ItemID is different after each save :( So it's very difficult to quickly check what changed in that documents... Please could it be possible to keep their value when saving again the same document ? | ||||
Steps To Reproduce | Just open a Scribus document, change it slightly and resave it, all ItemID will change. | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
|
|
|
please, if you make changes to the way item IDs work, make them not editable! the label a user can attach to an item should be just that, a label, not the id used by scribus internally. this is also valid for all resources like colors and styles! (that is: never use user input for internally referencing resources... not translate the references). |
|
Yes, I agree with you :) I know they're internally used and shouldn't be changed by user, but it's really annoying Scribus decides to change them all after every save :( If nobody can have a look to this "issue", I could eventually fix it myself (and propose a patch), but since I never modified Scribus code, I prefer to let experts do that :) About your comment "this is also valid for all resources like colors and styles", there are also problems with styles and colors that are internally referenced in SLA file using user input, which is I think a bad idea :s |
|
+1 I keep Scribus documents under version control (using Git). Version control becomes much more useful when files are diffable and mergeable. Thanks to the human-readable XML format, Scribus documents would be very easy to diff and merge, if it weren’t for these changing ItemIDs. |
|
Indeed :) I really don't understand why ItemIDs are not kept :( |
|
I looked into this and the problem is, that the ItemID is not some value stored alongside other values inside the class, but it's rather derived from the qHash of the pointer to the instance. This way, the ItemID will change, when the location in memory changes - which is obviously the case when loading an old .sla file. IMO, the ItemID should really be a value stored inside each instance which gets randomly initialized on creation. |
|
If that is so, then why does the ItemID need to be written to the XML file at all? (I haven’t looked at the code.) |
|
I think some other tags/options could be referencing them by ItemID but I'm not sure :( |
|
Yes, there are definitely references to ItemIDs in the sla. However, I did not see a relevant reading from the sla of those on first glance - but I need to check more thoroughly again. |
|
Changing ids every time document is Saved prevents any usefull diff or version control. Keeping them would enable that. |
|
+1 for that topic :-). As a work around, I wrote a perl script that temporary sets all ItemID = "0" before I commit my changes. |
|
Setting all ItemID to 0 prevents reopening the saved files @emmkei isnt ? how do you envision the use of such id-stripped files ? |
|
@JLuc: From my experience, Scibus is opening these files as well as with changing the IDs to any other value (I hope I did not miss anything...). Therefore I would also raise the question from cwalther: Why do we need these values in the sla-file? |
|
I really thought ItemID were referenced by other items, but in my own SLA files, it's not the case, each ItemID is used only once ;p |
|
I also don't see any refs |
|
I too have the issue of changing ItemIDs in combination of having the Scribus file in version control. I tried removing the ItemID attributes, which didn't cause any issues. They get recreated on load and stored in the save. Reading the code it seems that ItemID is used by Scribus internally, but that there is no direct need to store it in the file. It would be interesting to know what happens if users change ItemIDs to be non-unique. The PageItem rng schema lists ItemID as non-optional. I created an XSLT 1.0 transformation to remove the ItemIDs. I plan to to implement it as a git hook as a temporary workaround. ```xml <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <!-- Identity template to reproduce content --> <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> <!-- Suppress ItemId --> <xsl:template match="@ItemID"/> </xsl:stylesheet> ``` Can be executed like: xsltproc -o input.sla remove-itemid.xsl output.sla I provide this code snippet as public domain or in close proximity using creative commons zero clause license. |
|
Interesting, thanks :) I made a little script in PHP to simplify them, they are replaced by a simple counter starting from 1. But it would be better if it could be changed directly in Scribus :) |
|
Interesting thanks :) I made a little PHP script to replace ItemID by a simple counter starting from 1. But it would be better if it could be changed in Scribus directly :) <?php if ($argc < 2) { print "Syntax: php ".__FILE__." <SLA file>\n"; exit(1); } $file = $argv[1]; $filename = pathinfo($file, PATHINFO_FILENAME); print "Processing $file\n"; $content = file_get_contents($file); $id = 1; if (preg_match_all("/ItemID=\"([0-9]+)\"/", $content, $regs, PREG_PATTERN_ORDER)) { foreach($regs[1] as $oldId) { if (preg_match_all("/\"($oldId)\"/", $content, $regs2, PREG_PATTERN_ORDER)) { if (count($regs2[1]) > 1) { print "- $oldId found more than once, skip\n"; continue; } } $content = str_replace("\"$oldId\"", "\"$id\"", $content); ++$id; } } print "Replaced $id Item IDs\n"; file_put_contents($filename."_fixed.sla", $content); |
|
Well, i guess that removing them from Scribus is not very hard: just remove the variables that read and write until Scribus compiles and runs again... Then upload a patch : - ) And if this refactoring does not work, it means that Scribus needs the Ids. I'm a bit worried, about the absence of comments from Jean and Craig on this, but it could be a patch that is easy enough to create for the people who already have analyzed the working of the Ids in the .sla... |
|
There are references to ItemIDs that link between items. Removing them is not possible - certainly not where we are in our release cycle. It may have been introduced with Notes/Marks to link Footnotes to their master frames, but I'd have to dig through history of commits. |
|
Yes it arrived with https://bugs.scribus.net/view.php?id=10730 . It's required when using functionality for Marks/Notes. We'd need a suitable replacement, perhaps using QUuid() |
|
Looking at the source code I conclude that the ItemID has its use, also in the saved file, and so my previous suggestion of removing it will not work in all situations. I looked into the file handling in scribus/plugins/fileloader/ The ItemID attribute determines if isNewFormat boolean is set. ItemID is also used for linked frames using NEXTITEM attribute. There might be more use-cases where ImageID is used, I haven't looked any further. So this comes back to the comments by @deep42thought that the value should be read and saved, not recreated. Current code for most cases in scribus150format_save.cpp, similar in scribus170format_save.cpp: void Scribus150Format::SetItemProps(ScXmlStreamWriter& docu, PageItem* item, const QString& baseDir){ ... docu.writeAttribute("ItemID", qHash(item) & 0x7FFFFFFF); If NEXTITEM attribute it set, it actually calculates the pointer hash, rather than storing the known ID value. The change in 2015 to prevent unsigned ints in the hashes exposes locations where the hash calculation takes place: https://github.com/scribusproject/scribus/commit/8d7875d965fa25c3ccb142b7086a20be41f5939f 0012940: Fix qHash returning uints when we are only storing ints. Basic fix for 1.5.0 git-svn-id: svn://scribus.net/trunk/Scribus@19901 11d20701-8431-0410-a711-e3c959e3b870 I would expect the code to store item.ItemID if available and otherwise generate an ID, which could be based on the hash. Similar to how other attributes are stored. |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-06-12 08:33 | kervala | New Issue | |
2017-06-12 08:33 | kervala | File Added: Capture d’écran (201).png | |
2017-06-12 12:15 | ale | Note Added: 0044034 | |
2017-06-12 12:29 | kervala | Note Added: 0044036 | |
2017-10-28 08:45 | cwalther | Note Added: 0044605 | |
2017-10-28 08:58 | kervala | Note Added: 0044606 | |
2020-07-11 19:48 | deep42thought | Note Added: 0047821 | |
2020-07-12 18:54 | cwalther | Note Added: 0047825 | |
2020-07-12 19:02 | kervala | Note Added: 0047826 | |
2020-07-12 19:41 | deep42thought | Note Added: 0047827 | |
2020-07-12 21:17 | JLuc | Note Added: 0047828 | |
2020-12-15 09:45 | emmkei | Note Added: 0048558 | |
2020-12-15 12:22 | JLuc | Note Added: 0048563 | |
2020-12-15 13:00 | emmkei | Note Added: 0048564 | |
2020-12-15 13:09 | kervala | Note Added: 0048565 | |
2020-12-15 17:08 | emmkei | Note Added: 0048569 | |
2025-01-04 08:11 | nicorikken | Note Added: 0051862 | |
2025-01-04 09:21 | kervala | Note Added: 0051863 | |
2025-01-04 09:22 | kervala | Note Added: 0051864 | |
2025-01-04 09:58 | ale | Note Added: 0051865 | |
2025-01-05 10:00 | cbradney | Note Added: 0051873 | |
2025-01-05 10:13 | cbradney | Note Added: 0051874 | |
2025-01-05 11:08 | nicorikken | Note Added: 0051875 |