Thanks, it functions now. Consider the issue closed.

I found the issue that caused this problem and wanted to bring it to your attention. The main namespace display style control also appears in the user's namespace. https://en.wikisource.org/wiki/File:User_ineuw_sandbox1.jpg.

One of the things we discussed but wasn't implemented was the ability to remember zoom and pan position across pages. Implementing scroll and pan remembering across pages would effectively nullify any of the current issues wrt to scrolling to specific areas of pages since you should be able to pan the page once per every Index: page and then not have to adjust pages until you encountered (say) a text page.

I believe that you are under a misconception. Remembering zoom position and size between pages is irrelevant. Editing is better served by the current default reset of each new page opened for editing. Default magnification and the top of the page where editing always begins. Magnification is great for a closeup look, scrolling is far easier than sliding a djvu image 4 - 5 times to get to the text below an image (even when the djvu is minimized). There is no vertical real-estate to speed this up. Doing this thousands of times ends with me complaining here.

Thanks for the reply, it's much appreciated. So far the problem is corrected FF v100+, as you mentioned. Posting here was my last resort, because this offset became an issue with an earlier version using the Linux Mint Edition of Firefox. https://github.com/linuxmint/cinnamon/issues/10776.

You are assuming and pontificating. I happen to look at the sandbox9 occasionally if it is still aligned, but I closed it before purging the djvu page. Then, I reopened it on a hunch. If you would have taken the trouble to check the other closed sandboxes, you may have noticed that all of them are off. Shall I send you more photos?

This issue is best solved by the use of Autokey in Linux and Autohotkey in Windows 10, and not by adding application based shortcuts. This allows any user to assign whatever they want and need. Sometimes, when I edit in French Wikisource, I simply use another keyboard definition definition file. Using the same key combinations but the scripts which are activated by user assigned key, in French.

In T308091#7919932, @Aklapper wrote:

@Ineuw: For future reference, please use the feature request form (linked from the top of the task creation page) to create feature requests, and fill in the sections in the template. Thanks.

This feature used to be available, then removed because of technical issues,

Reference welcome.

but never installed/activated in Seadragon.

What is "Seadragon"?

Can you please fix this feature, as promised.

Where to find some promise?

@Soda, The new system is very good for text only pages, BUT, I can give you a 1,000 examples I am working on currently. Please attempt and edit a page with images and text. https://en.wikisource.org/wiki/Page:Africa_by_%C3%89lis%C3%A9e_Reclus,_Volume_3.djvu/590. Images are surrounded by text and navigating around an image without scrolling doubles my time of proofreading a page. This may sound crazy but I see results in my recent contributions on WS.

Is there a chance for the image scrolling to be restored?

The image scroll feature doesn't exist. Is there a plan to revive it?

"It doesn't need to exist to edit the page. A red link always takes you directly to the edit form. All you have to do is click on it."

Are you referring to this link on the patch demo? because it's no longer exists for testing [[Page:Shen_of_the_Sea.pdf/45]]

@Inductiveload, I apologize for the delayed reply. I get no emails from this site, even though it's properly configured.

Thanks for the reply. As far as I understand the information in 'patchdemo' is that the order of mouse scroll behaviour would be:

@Inductiveload, I am not blind to the shortage of developers, but from my viewpoint, I am also aware that Wikipedia offers an excellent opportunity for honing and refining programming skills.

@Inductiveload, none of the above suggestions scroll the content. Were there any problems with the previous arrangement? If not, these changes may entertain and occupy the developers, but don't nothing to help editors. Please don't break something that works. Can I disable the magnifier on the pages I want to work and get back scrolling until this is sorted out and functioning?

Of course not. I am heading there. . . . and thanks

I understand the position you're in, but there has to be a better way to test software. Is there a way for me to block magnification in my vector.js, and restore to just scrolling until the problem resolves itself?

Please keep away from two handed actions (mouse + keyboard) whenever possible.

I apologize for this late reply because I am not in the habit of ignoring posts addressed to me. The character-insert is accessible at all times. My only issue is that it doesn't stay on top (above the edit window), as how I set it in my vector.js.

Much thanks @Aklapper and @Billinghurst. The info is missing and I will pursue it in the talk pages.

The Global preferences were not set up correctly, and the setting didn't cascade to the local preference. The second checkbox was unchecked, the purpose of which I don't understand. Why some of the the Global references have a pair of checkboxes. I searched Mediawiki for an explanation but found nothing. In my case, the left checkbox was selected and the right wasn't. This is indicated in the attached image.

Disabled Global preferences and the preview is working properly.

@Aklapper If I am correct, perhaps the title of this ticket should be changed to something like "Link between Global preferences and Local preferences is broken"?

IneuwPublic has no global account on Wikimedia and the User Preferences Preview display is selected, which works.

You and I have taken exactly the same steps, in the same sequence and as you can see in the attached photo. The photos were taken hours ago and doublchecked them now. I noticed that the global preview is checked and the user preview is blank.

I assume that it has to do with "global" because I am always logged in automatically on every visited wiki website and the same problem persists.

The Preference options in my second account IneuwPublic differ from the Ineuw account in that there are no global account settings.

@Aklapper "Enabling "Horizontal layout when editing in the Page: namespace" on https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-editing :)"

Just started using it in English Wikisource and its working.

@Aklapper Please clarify what is missing in the description? I know that it happens in FF 75.0 which I am using now, but I started the problem data collection when FF was version 74.

Inserted image in description, of the page layout with the issue.

There are other issues following the above steps, but it's possible that if this is corrected, the other issues may be corrected.

I have all the information on the steps to take to replicate the problem, but there are at least one other problem discovered while using the same steps. I would like to create a new bug report for one issue and have this bug report re-titled or annulled please.

@Aklapper, thanks for the reply and the info.

After experimenting, the font size returns to the user defined size when the page is refreshed, but this process must be repeated for every page.

The problem is the syntax highlighter. After disabling it, the layout corrected itself.

Neither Phe's OCR in my user space nor the Gadget OCR work on some volumes. You can test this:

What is the current state of this task?? None of the substitutes (like Google OCR) come near in quality of character recognition.

OCR failure is not universal. For details, please see this post in English Wikisource:
https://en.wikisource.org/wiki/Wikisource:Scriptorium/Help#OCR_failure_is_not_universal

Is it possible for me to see the stages of work on this problem? I ask because it's working again, but don't know if the fix is permanent.

Used it on English Wikisource at 04:53, 25 July 2019 (UTC) and it worked. But, now it's dead again. What was done at the indicated date and time to make it work?

I should have mentioned that I only use the source editor.

Yes please.

It was resolved within a few minutes. If I can't close, then please close it. ty.

https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-gadgets

It also affects the rendering of the GUI. With each scroll down the page, the "Save" button appears on the middle of the page/display.

@Phe, The same request as Jan.Kamenicek's above. Is it possible to implement the OCR locally?

I tested it when logged out and everything worked, so I looked in both the common.js and common.css. There were copied css settings from another editor, one of which had a max-height setting for the main textarea dimensions. After removing it, everything is as it should be.

Please close this report. It is repaired.

@Aklapper. It works when logged out AND the header/footer rows are 3 lines!!! So, deleted all my Wikipedia related cookies, logged back in and the problem returned. Will remove my common.js & common.css and see what happens. If it's still not working, the problem might be my preferences \edit or the \gadgets.

Yes, the header was always 3 lines, before I reported T212999 or T213043 bugs. These bugs were related to the headers and footers.

Using Firefox 66.01 in Windows 10, and Firefox 66.0 in Linux Mint 19.1, as well, the latest Vivaldi-snapshot in both Windows and Linux. The problem is the same in both browsers. Also uploaded this image at Wikisource with explanation. https://en.wikisource.org/wiki/File:T219048.jpg

I also received two automated emails, the numbers are different but I am sure that they are related to this bug.

Everything is fine. Thank you. Please close this report.

The bug is corrected and the ruler displays correctly in the footer. Thanks to all.

Thanks to both of you. I saw the <hr> auto issue, and I have no problem waiting for the "visibility" issue to be resolved however long it takes.

AKlapper, thanks for your instructions. Will do so with future bug reports.

@Aklapper, I must have used a simple bug report form because the fields indicated in the tutorial did not exist.

@Aklapper, this issue occurs on the French Wikisource as well, which means that it occurs on every site that uses the Proofread extension. Now that I work in a language and a website that is less familiar, it requires previewing the work more often that before and thus the number of appended empty lines increases.

@Klapper, Thanks. I don't need and expect instant resolution. I was just curious about the process. For me the inner sanctum of Wikimedia's technical process is a complete mystery. It's sort of a netherworld. :-)

@Aklapper, Just asking what is the status of this issue? Thanks

This is the editor I am using https://www.mediawiki.org/wiki/Extension:WikiEditor

@Aklapper, I am using the "Extension WikiEditor" 2010, Desktop, "This can be seen when "Enable enhanced editing toolbar" is enabled in Special:Preferences. as mentioned in my previous comment."