Last modified: 2007-12-23 12:52:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T14238, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 12238 - ProofreadPage: Automatically link to other pages for multipage PDFs and DjVus
ProofreadPage: Automatically link to other pages for multipage PDFs and DjVus
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
ProofreadPage (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-08 13:58 UTC by Thomas Bleher
Modified: 2007-12-23 12:52 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to automatically link to other pages of multi-page documents (2.02 KB, patch)
2007-12-08 13:58 UTC, Thomas Bleher
Details
patch (6.45 KB, patch)
2007-12-18 19:02 UTC, ThomasV
Details

Description Thomas Bleher 2007-12-08 13:58:40 UTC
Created attachment 4418 [details]
Patch to automatically link to other pages of multi-page documents

Currently, the ProofreadPage extension doesn't link to other pages of a multipage PDF or DjVu document.
Attached patch changes this, so that when no index for the file is found, links to the other pages are created.

I can commit this myself, but I'd like to get some feedback first if this approach is OK.

BTW: This patch is live at e.g. http://spiele.j-crew.de/wiki/Scan:9s_schdM.pdf
Comment 1 ThomasV 2007-12-12 23:14:47 UTC
this is interesting... but I have a few questions: 

1. currently on wikisource, users sometimes use 
a page ordering in the index that differs from the 
page ordering of the document. they do this in order 
to have page numbers match in a book and in the 
associated djvu. it seems to me that possibility 
would remain, because your patch first checks for 
the existence of an index... but I want to be sure 
that it won't break anything.

2. the index page has another function than linking 
(not yet active on wikisource) : it displays the state 
of advancement of pages using css attributes (quality). 
see for example http://www.xarax.eu/wiki/Index:Das_vollkommenste_Hautskelet?action=purge

Now, if there is no manually created index page, I guess 
this list of colored links should be generated automatically 
(on a special page that can be included in pages, or invoking 
a parser command).

Comment 2 Thomas Bleher 2007-12-14 16:41:45 UTC
About question one:
Yeah, the patch only changes behaviour in case no index page can be found.
As soon as one is created, everything works as before.

About question two:
Currently the code doesn't link to any index page, which is OK for me, but
probably not for wikisource. I think creating a special page that displays
the needed information and linking to this page if no index page can be 
found would be the best solution.

Comment 3 ThomasV 2007-12-17 14:41:43 UTC
hmm, instead of creating a special page, maybe the Image: page could display 
that information, and replace the index page. 

Comment 4 Thomas Bleher 2007-12-17 15:25:10 UTC
Interesting idea, but I'm not quite sure where you'd hook the ImagePage class. The only hook available (AFAICS) is ImageOpenShowImageInlineBefore, which doesn't seem suitable, so you'd probably have to add a new one.

On second thought, you could insert some text into the image description, using the normal parser hooks.
Comment 5 ThomasV 2007-12-17 15:39:51 UTC
besides that, there is a bug in yout patch (I am testing it now) :
if the page namespace is not created, it prepends a double 'Page:' 
prefix in the links
Comment 6 ThomasV 2007-12-18 19:02:38 UTC
Created attachment 4448 [details]
patch

ok, here is a new patch, that creates the page list in a canonical index page.
I have not tested it toroughly, so I will not commit it now. Comments welcome.
Comment 7 Thomas Bleher 2007-12-19 10:11:02 UTC
WorksForME :) (ie I have just tested it, although not very thoroughly, either)

The only thing I liked more about my patch is that the link to the first page didn't have the /1 tagged to it (so the link to the first page was Scan:document.pdf, not Scan:document.pdf/1).
I think this more consistent with single-page documents, but others would surely argue otherwise, so that's your decision.

OTOH, if you leave it like it currently is, the main page (ie Scan:document.pdf) could display the overview, like the index, and Scan:document.pdf/1 could display the first page.

Just some ideas...
Comment 8 ThomasV 2007-12-19 12:41:05 UTC
ok, commited.
I do not know what to do about the /1, will decide later
Comment 9 ThomasV 2007-12-23 12:52:47 UTC
I guess it is better to keep /1 for the first page, because it 
will make life easier for bot programmers, and because we already 
have a lot of documents using this convention.
so, I'm marking this bug as fixed. thanks for the patch.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links