openoffice plugin very slow
for me using firefox 3.5.16 and openoffice 3.2.1 under debian linux the zotero openoffice plugin works awfully slow. (pentium V, 2 Ghz)
In a document containing about 190 references (90 unique) it takes over 15 seconds until the "insert reference" dialog appears. Inserting the choosen reference takes additional 5 seconds.
I found a view threads from the past like: http://forums.zotero.org/discussion/2070/
Is this still the same issue?
For me it doesn't make any difference if there is an bibliography includes at the end or not.
In a document containing about 190 references (90 unique) it takes over 15 seconds until the "insert reference" dialog appears. Inserting the choosen reference takes additional 5 seconds.
I found a view threads from the past like: http://forums.zotero.org/discussion/2070/
Is this still the same issue?
For me it doesn't make any difference if there is an bibliography includes at the end or not.
Should zotero with large documents (about 100 pages) be only usable on brand new hardware?
Firefox 3.16, LibreOffice 3.3.1, Zotero 2.1
Debug ID is D1986659789.
I'm not sure what a Pentium V is, but the 2 GHz Pentium 4 was first released more than 10 years ago. It is 4 years older than the first Firefox release, and 2 years older than Mozilla 1.0. If this is really what you have, you might want to seriously consider upgrading.
great, I'm excited. The first invocation still needs about 15 seconds. But the following edits and inserts work fluently (3-4 seconds). Now It's really usable. Was is a bug which affected my specific configuration? Or did other people have the same trouble?
(it's a Pentium M - (IV) not V in a thinkpad t30. Indeed, it's a couple of years old.)
problem is of course that the database is not compatible anymore with 2.0 - this upgrade business is a real trap for ppl with slow computers - zotero should give a clear warning!
is there any way to downgrade my db?
i can't risk using a trunk on 5 years worth of research data. when will this trunk be included in a stable version?
as already written in this thread i downgraded to version 2.0. open office referencing is running fine again. only problem is that i have data, from the 23rd of march onwards (naively trusting the update when importing into zotero), which i can't import into the 2.0 version.
as described i tried 'Restoring from the last upgrade backup', exported from 2.1 & tried to import into 2.0 - but i got an error message 'The selected file is not a supported format'.
the only hints i found were these:
http://forums.zotero.org/discussion/15184/the-selected-file-is-not-a-supported-format/
&
http://forums.zotero.org/discussion/14193/bug-report-error-in-rdf-importing-and-exporting/
i tried to export every possible format + as discussed in the 'file is not a supported format' thread different language settings. but no luck. giving up after trying for 4 hours. any help/hints of how to get my data back into version 2.0 would be appreciated.
Just a thought.
i would not like to put this document forward as a guinea pig. if regression can occur (& it seems likely given the warning messages on the trunk page) i'd rather go with a stable version over the next months, meaning either a stable 2.1./2.2. office plugin comes asap (which leads to the question when?) or i'll simply continue with 2.0. (which leads to the question of getting back my data from 2.1. into 2.0.?).
though i'm happy to give the trunk a try & i will report back - but unlikely wanting to rely on it (given the warning messages)...
nevertheless what is the bigger problem here is that many reference fields definitively get corrupted, in about a 10th of the fields within the document i get characters added to the year like 'ap', 'j', 'e', etc. so this trunk is definitively a 'no go' for now.
leaving me with 2.0 for now & the question of how i get my data back into 2.0 (stuff i have been adding to zotero from the 23rd march onwards), because of this error msg (as described earlier): 'The selected file is not a supported format'. again any hints/help appreciated on this one - or i'll have to bite the bullet redo the last 3 wks again...
& as stated above the only hints i found for a possible solution were these:
http://forums.zotero.org/discussion/15184/the-selected-file-is-not-a-supported-format/
&
http://forums.zotero.org/discussion/14193/bug-report-error-in-rdf-importing-and-exporting/
but no luck so far...
If it's the latter, create an error report ID and paste the RDF of a singe entry that doesn't work to gist.github.com, create a public gist and post the URL here.
unfortunately it is the latter.
report ID is 631868291 & public gist url is https://gist.github.com/911719
In my case it was always slow, so the downgrade won't be a solution for me. On the other hand this "trunk"-option sounds quite scarry... Has anyone tried this yet?
1. Yes, in some fields the field code was removed.
2. No, it isn't faster at all.
Now, because I want to continue with my work, and want to end the experiment - can you tell me how to restore zotero in its' previous condition? I don't see any "OpenOffice Integration Trunk XPI" among the plugins in Firefox or Openoffice to simply uninstall it.
And Please write if you have any other Ideas how can I make it work faster... Thank you!
OpeOffice.org Integration 3.5a1: first citation 16 s, every next 12 s, edit cit. 12 s.
Trunk XPI: first citation 12 s, every next 7 s, edit cit. 7 s.
PS. I use the latest Firefox version, Openoffice 3.2.0. and Ubuntu 10.04.
Unfortunately, the experiment broke a number of disambiguation tests, so it's not useful in its current form. With a few more tweaks there might be potential for the approach I tried, however. I'll preserve the code from the experiment, and will look at it again when I have a bit of time to dwell on it.