View Issue Details

IDProjectCategoryView StatusLast Update
0014861ScribusInternalpublic2025-01-05 11:08
Reporterkervala Assigned To 
PrioritylowSeverityfeatureReproducibilityalways
Status newResolutionopen 
PlatformWindowsOS10 (64 bits)OS Version10.0.14393
Product Version1.5.3 
Summary0014861: Keep same ItemID when saving
DescriptionHi 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 ReproduceJust open a Scribus document, change it slightly and resave it, all ItemID will change.
TagsNo tags attached.
PatchNo

Activities

kervala

2017-06-12 08:33

reporter  

Capture d’écran (201).png (159,484 bytes)   
Capture d’écran (201).png (159,484 bytes)   

ale

2017-06-12 12:15

manager   ~0044034

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).

kervala

2017-06-12 12:29

reporter   ~0044036

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

cwalther

2017-10-28 08:45

reporter   ~0044605

+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.

kervala

2017-10-28 08:58

reporter   ~0044606

Indeed :) I really don't understand why ItemIDs are not kept :(

deep42thought

2020-07-11 19:48

reporter   ~0047821

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.

cwalther

2020-07-12 18:54

reporter   ~0047825

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.)

kervala

2020-07-12 19:02

reporter   ~0047826

I think some other tags/options could be referencing them by ItemID but I'm not sure :(

deep42thought

2020-07-12 19:41

reporter   ~0047827

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.

JLuc

2020-07-12 21:17

developer   ~0047828

Changing ids every time document is Saved prevents any usefull diff or version control. Keeping them would enable that.

emmkei

2020-12-15 09:45

reporter   ~0048558

+1 for that topic :-).
As a work around, I wrote a perl script that temporary sets all ItemID = "0" before I commit my changes.

JLuc

2020-12-15 12:22

developer   ~0048563

Setting all ItemID to 0 prevents reopening the saved files @emmkei isnt ? how do you envision the use of such id-stripped files ?

emmkei

2020-12-15 13:00

reporter   ~0048564

@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?

kervala

2020-12-15 13:09

reporter   ~0048565

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

emmkei

2020-12-15 17:08

reporter   ~0048569

I also don't see any refs

nicorikken

2025-01-04 08:11

reporter   ~0051862

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.

kervala

2025-01-04 09:21

reporter   ~0051863

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 :)

kervala

2025-01-04 09:22

reporter   ~0051864

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);

ale

2025-01-04 09:58

manager   ~0051865

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...

cbradney

2025-01-05 10:00

administrator   ~0051873

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.

cbradney

2025-01-05 10:13

administrator   ~0051874

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()

nicorikken

2025-01-05 11:08

reporter   ~0051875

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.

Issue History

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