Xowa: Are there any ways to view .svg files inside xowa?

[khanhhung2512]

OK. I have to make due with the pre-built October English Wikipedia for now.

Here's my problem. When I accessed this page in Xowa en.wikipedia.org/wiki/Unix, the first picture was too small to read, so I clicked on it. I was directed to en.wikipedia.org/wiki/File:Unix_history-simple.svg, but it was like the following picture:

So, are there any ways to view .svg files inside xowa? I didn't download the images package but have web access enabled.

[gnosygnu]

Thanks for the details.

This is a bug with the pre-built HTML databases. It should open up a mock-up page of commons with the file. (The self-built Wikitext databases do). Instead, it's opening up to no file.

I'll fix this for next week's release (not tomorrow's). In the meantime, you can always get the svg by:

• Right-clicking the image and clicking "Save File As"
• Looking at "View HTML" and getting the file path from the HTML

Hope that helps.

Thanks.

[khanhhung2512]

Right-clicking the image and clicking "Save File As"
Looking at "View HTML" and getting the file path from the HTML

The saved .svg file is 0 bytes, and I don't see "View HTML" anywhere.
Btw, now it says "commons.wikimedia.org must be installed in order to view the file". Should I import commons.wikimedia.org? If not, what purposes will importing commons.wikimedia.org serve?

One more thing, in order perform importation, the following dumps are needed:

• Commons, Wikidata: 'pages-articles', 'categorylinks', and 'page_props'
• Wikipedia (English, Simple, etc.): 'pages-articles', 'categorylinks', 'page_props', and 'pagelinks'

Right?

[gnosygnu]

The saved .svg file is 0 bytes,

I tried again now, and it does give a 22 kb file. Unfortunately, it's a PNG, not an SVG. Not sure why it's only 0 bytes on your side...

and I don't see "View HTML" anywhere.

There's a "View HTML" link next to "Read", and "Edit" in the top right hand corner of the page. You can also do:

• Main Menu: View -> View HTML
• Keyboard shortcut: Ctrl+U

On my machine, it comes up as: D:\xowa\file\commons.wikimedia.org\thumb\7\7\9\3\Unix_history-simple.svg

However, in either case it's a png, not an svg, so I'm not sure if that is what you're looking for

Btw, now it says "commons.wikimedia.org must be installed in order to view the file".

This is an old message that's no longer relevant today. I changed XOWA several months ago to "simulate" commons pages when commons wasn't available. Unfortunately, this simulation only worked for wikitext databases (imported), not HTML databases (pre-built). I'll fix this in a future release.

Should I import commons.wikimedia.org? If not, what purposes will importing commons.wikimedia.org serve?

There's no need to import commons unless you want the metadata in commons. For example, everything in the Summary section on this page: https://commons.wikimedia.org/wiki/File:Laudtee_Meenikunnos.jpg . Otherwise, a commons import has no effect on any of the other wikis.

One more thing, in order perform importation, the following dumps are needed:
Commons, Wikidata: 'pages-articles', 'categorylinks', and 'page_props'

Yes for both Commons / Wikidata. Again, you probably don't need commons. Wikidata is still useful, especially if you want to see inter-wiki links between languages (for example, you want to see the Vietnamese page for Earth when viewing en.wikipedia.org/wiki/Earth)

Wikipedia (English, Simple, etc.): 'pages-articles', 'categorylinks', 'page_props', and 'pagelinks'

Yup. Though you can skip pagelinks if you want. As said earlier, it only generates a more sophisticated sorting sequence.

Hope this helps.

[khanhhung2512]

This is a bug with the pre-built HTML databases. It should open up a mock-up page of commons with the file. (The self-built Wikitext databases do). Instead, it's opening up to no file.

Actually, I just imported Simple English and got the same error when opening .svg files.

However, in either case it's a png, not an svg, so I'm not sure if that is what you're looking for

So, are there any ways for me to view the .svg file?

Btw, you said yesterday that for xowa, you just need to overwrite the old build with the new build. If that's the case, what is the function of the upgrade files (e.g. xowa_upgrade_windows_64_v3.10.4.6.exe) here https://github.com/gnosygnu/xowa/releases/

[gnosygnu]

This is a bug with the pre-built HTML databases. It should open up a mock-up page of commons with the file. (The self-built Wikitext databases do). Instead, it's opening up to no file.

Actually, I just imported Simple English and got the same error when opening .svg files.

Yeah, I checked it now, and you are right. This is broken even for Wikitext databases.

I'll put in a fix for tomorrow night's release.

BTW: I usually like to credit users for reporting bugs in the app. There will be a line in the XOWA change log with something like "Fix unnecessary requirement for commons when clicking on images {detected by anonymous}". Let me know if you would like to be cited by nickname or would rather remain anonymous

However, in either case it's a png, not an svg, so I'm not sure if that is what you're looking for

So, are there any ways for me to view the .svg file?

No, unfortunately not. Historically, XOWA uses the png not the svg to display in the browser. Keep in mind that Wikipedia also displays the png not the svg. For example, on https://en.wikipedia.org/wiki/Unix, Wikipedia uses https://upload.wikimedia.org/wikipedia/commons/thumb/7/77/Unix_history-simple.svg/300px-Unix_history-simple.svg.png

XOWA could change this to use an svg instead, but it could require a lot of changes to code. It's something I'll keep in mind for a future release, but not anything I can promise for now

Btw, you said yesterday that for xowa, you just need to overwrite the old build with the new build. If that's the case, what is the function of the upgrade files (e.g. xowa_upgrade_windows_64_v3.10.4.6.exe) here https://github.com/gnosygnu/xowa/releases/

The upgrade packages are "slimmer" versions of the app package. They only contain changes made in the last month, and not the full install. Most users (upwards of 90%) probably should only use the app package. For users who want to update month to month, or have updated one week and want to get a patch the next, they can save some download bandwidth and use the upgrade package.

Hope this helps.

[khanhhung2512]

BTW: I usually like to credit users for reporting bugs in the app. There will be a line in the XOWA change log with something like "Fix unnecessary requirement for commons when clicking on images {detected by anonymous}". Let me know if you would like to be cited by nickname or would rather remain anonymous

Nickname sounds cool. Sign me in.
Anyway, is it possible to get a bigger png?
Another issue is wiki removal. I followed the instructions here http://xowa.org/home/wiki/App/Import/Removal.html, but the wiki still exists in the left panel. There's no page, of course, but is there a way to remove the link there as well?

XOWA could change this to use an svg instead, but it could require a lot of changes to code. It's something I'll keep in mind for a future release, but not anything I can promise for now

Actually, I just checked and the problem happens with .jpg and .png files as well.

[gnosygnu]

Nickname sounds cool. Sign me in.

Cool. I cited you as khanhhung2512 in http://xowa.org/home/wiki/Change_log.html#v3.11.2.1_.282016-11-13.29 . Let me know if you preferred something else, and I'll update it later.

Anyway, is it possible to get a bigger png?

Well, if you're sometimes online, yes. Tonight's release now has a fix for the "click on image" issue (thanks to your report). After you click on an image, it will download a larger image. In addition, there will be a link on the page to download "Full Resolution". For the svg, it will download the actual svg file (and try to open it with your default program)

If you're always offline, then probably not. The XOWA image databases will only contain images used in the articles, so a lot depends on whether a larger version of the same image is used elsewhere. Unfortunately, there's no easy way to do a reverse search (find me what pages use this image)

Another issue is wiki removal. I followed the instructions here http://xowa.org/home/wiki/App/Import/Removal.html, but the wiki still exists in the left panel. There's no page, of course, but is there a way to remove the link there as well?

Have you tried removing the entire directory? For example, for simple wikipedia, an empty folder of "C:\xowa\wiki\simple.wikipedia.org" will still generate an entry in the left panel. Deleting the folder and restarting XOWA will remove the entry entirely.

I know that may be counter-intuitive (empty folders create entries), but it makes application startup quicker (without having to inspect each directory for valid wikis)

XOWA could change this to use an svg instead, but it could require a lot of changes to code. It's something I'll keep in mind for a future release, but not anything I can promise for now

Actually, I just checked and the problem happens with .jpg and .png files as well.

Not sure I follow. I was saying that svg files are different in that svg files are not directly used, but their png conversions instead. Are you saying that the jpg and png files are also being unnecessarily converted to png? (a specific example would help) Or that they are too small? (a specific example would help here too) Or that clicking on them also doesn't navigate to a new page? (this is fixed in tonight's release)

Hope this helps

[khanhhung2512]

On my laptop, I have to click show preview to see the picture.

[gnosygnu]

Ok. We're discussing this on IRC. This is what I see.

{EDIT: And this is my version}

[khanhhung2512]

On my desktop.

[gnosygnu]

First, a lot of thanks to @khanhhung2512 for spending time with me to get to the bottom of this.

There are a few issues when using "Full Resolution":

• XOWA can't handle spaces in the XOWA path. So "D:\xowa app" fails. "D:\xowaApp" would work
• XOWA can't handle some (all?) URL-encoded characters in images. So en.wikipedia.org/wiki/File:Elizabeth_II_greets_NASA_GSFC_employees,_May_8,_2007_edit.jpg fails because comma is encoded as %2C.
• XOWA might be jumping into Edit mode instead of Read mode when viewing an image in the File namespace. For example, en.wikipedia.org/wiki/File:MimiRogersApr09.jpg goes to the Edit tab on khanhhung2512's machine. On my machine it goes to the read tab. I'm not sure how this is happening, but I'll go through the code this week.

I'll get the first two fixed for the next release. The third will require some more investigation on my side.

[khanhhung2512]

I guess the following will help you debug the third issue:

20161114_070750.602 page.load: url=en.wikipedia.org/wiki/File:Victoria_Hall,_Westmount_1.JPG
20161114_070751.575 download pass: src='https://en.wikipedia.org/w/api.php?action=parse&format=json&redirects=1&page=File:Victoria_Hall,_Westmount_1.JPG' trg='mem/download.tmp'
20161114_070751.577 page_load fail: page=en.wikipedia.org/wiki/File:Victoria_Hall,_Westmount_1.JPG err=[err 0] null
[trace]:
gplx.xowa.addons.wikis.pages.syncs.wmapis.Xowm_parse_wmf.Parse(Unknown Source)
gplx.xowa.addons.wikis.pages.syncs.wmapis.Xowm_parse_wmf.Get_parse_or_null(Unknown Source)
gplx.xowa.addons.wikis.pages.syncs.core.Xosync_update_mgr.Update(Unknown Source)
gplx.xowa.addons.wikis.pages.syncs.core.Xosync_read_mgr.Auto_update(Unknown Source)
gplx.xowa.wikis.pages.Xowe_page_mgr.Load_page(Unknown Source)
gplx.xowa.guis.views.Load_page_wkr.Thread__exec(Unknown Source)
gplx.core.threads.Gfo_thread_pool.Run_wkr(Unknown Source)
gplx.core.threads.Gfo_thread_pool.Invk(Unknown Source)
gplx.Gfo_invk_.Invk_by_msg(Unknown Source)
gplx.core.threads.Thread_adp.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

[khanhhung2512]

Well, the third issue has just been resolved and I have no idea how that happened.

[gnosygnu]

I guess the following will help you debug the third issue:
20161114_070750.602 page.load: url=en.wikipedia.org/wiki/File:Victoria_Hall,Westmount_1.JPG
....
gplx.xowa.addons.wikis.pages.syncs.core.Xosync_read_mgr.Auto_update(Unknown Source)

Yup. Helps a lot!

The problem was with "Page sync". It tries to sync the page, but the specific URL doesn't exist. As such "Page sync" fails badly and causes the problems you see. Note that this also explains why it went away: "Page sync" runs once, and then doesn't run again for 24 hours.

I uploaded a preview build that fixes these issues. Please try the following:

• Download the Windows 64 bit build here: https://drive.google.com/open?id=0B9cb52zjL2rIZmlHS2RXbkdIdFE
• Unzip to your folder: "E:\Portable Programs\xowa"
• Delete the following file: "E:\Portable Programs\xowa\bin\windows_64\xowa\cfg\xowa_cfg_os.gfs"
• Launch XOWA
• Go to simple.wikipedia.org/wiki/File:Elizabeth_II_greets_NASA_GSFC_employees,_May_8,_2007_edit.jpg

This build handles all three issues above. Specifically:

• XOWA installed to a path with spaces doesn't cause failure (E:Portable Programs)
• A URL-encoded image doesn't cause failure (File:Elizabeth_II_greets_NASA_GSFC_employees%2C_May_8%2C_2007_edit.jpg)
• Page Sync enabled doesn't cause failure (home/wiki/Options/Page_sync)

Hopefully this works for you. I'm going to be an optimist and mark this issue resolved for now.

Let me know if there is anything else. Thanks again for all the follow-thru.

[khanhhung2512]

It seems to be working well. I'll report when there's an issue.

"Page sync" runs once, and then doesn't run again for 24 hours.

I thought that only applies to pages listed in the "Pages to sync" box, and others are updated when visited.

Btw, in case a new release fails for some reasons, will overwriting the new build with the old build completely reverse everything to the previous working state?

[gnosygnu]

It seems to be working well. I'll report when there's an issue.

Cool! Thanks for verifying.

"Page sync" runs once, and then doesn't run again for 24 hours.

I thought that only applies to pages listed in the "Pages to sync" box, and others are updated when visited.

Ugh. It should, but I see now that it actually gets ignored. I'll try to fix that for the next release.

Btw, in case a new release fails for some reasons, will overwriting the new build with the old build completely reverse everything to the previous working state?

Yup. Overwriting with an old build will go back to the previous working state 99% of the time. 1% of the time it may not because of database changes (so going to v1.0.0 is not a good idea)

Also, if something goes wrong you can always do this:

• Extract the old version to a new directory. Say, E:\xowa_new
• Move all folders in E:\xowa_old\wiki to E:\xowa_new\wiki
• Move all folders in E:\xowa_old\user to E:\xowa_new\user
• Delete E:\xowa_old
• Rename E:\xowa_new to E:\xowa_old
  But again, this should be a very rare circumstance

[gnosygnu]

I thought that only applies to pages listed in the "Pages to sync" box, and others are updated when visited.

Ugh. It should, but I see now that it actually gets ignored. I'll try to fix that for the next release.

This issue is also resolved in tonight's preview release. See: https://drive.google.com/open?id=0B9cb52zjL2rINTJ3RUhPdUtvV28

Note that by default it will only sync the Main_Page in any wiki (specifically, *:Main_Page) Feel free to customize to choose another.

Thanks!

[khanhhung2512]

Actually, it seems like Automatic Sync just stops working altogether.

[gnosygnu]

Thanks for the quick feedback. I tried again just now and it does work on my side. See the image below

Can you check your Options page? I changed the default, and it might be possible that you have the old value. Specifically:

• Go to home/wiki/Options/Page_sync
• Check "Pages to sync"
  
  
  
  • It should say *:Main_Page
  
  
  • It used to say Main_Page which is now wrong
  
  

Thanks.

[khanhhung2512]

I actually changed it to *:
I went to en.wikipedia.org/wiki/2016_Pacific_hurricane_season and it was different from the website, unless I manually clicked "Sync page".

PS: In order to check the issue, you'll need a pre-sync wikipedia.

[gnosygnu]

Thanks for the example.

I tried now, and it does work. See screenshot below. Specifically, I was looking for the change made regarding Tina and .6325 on Nov 17 17:32 (https://en.wikipedia.org/w/index.php?title=2016_Pacific_hurricane_season&type=revision&diff=750069697&oldid=749932242)

If you have it set to : then that would definitely not work. Try just or the asterisk only (no colon).

I just jumped on IRC if you want to troubleshoot further.

Thanks!

http://webchat.freenode.net/?channels=#xowa

[gnosygnu]

There were basically two items in this issue:

• Page sync usually failed when trying to sync a page in the File namespace
• Page sync was syncing all files: not just those listed in the Options page

Both of these were fixed in tonight's v3.12.1.1 release. I'm going to go ahead and mark this issue closed for now.

Let me know if I missed anything above.

Thanks.