Index talk:Star Lore Of All Ages, 1911.pdf

From Wikisource
Jump to navigation Jump to search

Astrological symbols[edit]

There is a choice to be made on whether to treat the astrological symbols in the text (see e.g. p.34 and p.58) as images (e.g. and ) or typographical characters (e.g. ♒︎ and ♈︎).

In the later case it becomes ok for the transcribed symbol to differ, vissually, from that in the source text in the first it is not. / Lokal Profil (talk) 19:43, 25 September 2022 (UTC)[reply]

I'd go with typographical characters -- we're aiming for matching content, not matching visually. JesseW (talk) 00:23, 26 September 2022 (UTC)[reply]
Lokal Profil: Zodiac symbols are a pain; if you don't do something special, emoji will be there. This was worked out for an astrology book I proofed. I have a symbol list, don't be shy that it is in my user space: User:RaboKarbakian/Symbols#Astronomy scroll a little for zodiac. The "something special" is to follow the character with ︎. I read a paper about this even, if you want to read this paper, just let me know. That list should be pasteable.--RaboKarbakian (talk) 01:59, 26 September 2022 (UTC)[reply]
(But use the symbol paste or the entity code for them, not images!)--RaboKarbakian (talk) 02:00, 26 September 2022 (UTC)[reply]
@RaboKarbakian, @JesseW: Thanks for the feedback! The reason I was even considering images was because the symbols don't always look like their modern unicode equivalents and I simply don't know enough about them to know if the difference is significant or not. But based on the feedback I'll go for the unicode/glyph solution, although there seems to be some non-zodiacal symbols which may still have to rely on images. Thanks also for the info on the postfix used to prevent them from ever being rendered as emoji (or at least to ask the browser to please not do it). /Lokal Profil (talk) 18:09, 26 September 2022 (UTC)[reply]
Would it be worth it to put up a template similar to Emoji presentation (on enwp )to add the postfix? It could make the source more legible by instead looking something like {{text glypth|♈︎}}? It would also make it easier to identify such cases in the future if additional workarounds are identified (since a quick search revealed that not all browsers respect the postfix). Lokal Profil (talk) 18:31, 26 September 2022 (UTC)[reply]
I'd recommending asking about making a template on Wikisource:Scriptorium; that's more likely to get wider attention. JesseW (talk) 19:52, 26 September 2022 (UTC)[reply]
My question was more if it's worth creating (actually doing it is something I'm fine doing mysef). /Lokal Profil (talk) 20:42, 26 September 2022 (UTC)[reply]
Yeah, it was answering the question of whether it's worth it that I was suggesting the Scriptorium for. JesseW (talk) 23:39, 26 September 2022 (UTC)[reply]
Ah, my apologies. /Lokal Profil (talk) 20:23, 5 October 2022 (UTC)[reply]
Lokal Profil Yes! That is a great idea! And if you can do this, all the better!--RaboKarbakian (talk) 20:45, 26 September 2022 (UTC)[reply]
A first draft. Examples on the talk page. /Lokal Profil (talk) 20:23, 5 October 2022 (UTC)[reply]
User:Lokal_Profil: ⚜︎ I just pasted the character from my symbols page. It would be nice if "alt" could be set with the name of the symbol. In this case, it was ⚜ ⚜ with alt="Fleur De Lis". But it doesn't need to do that to be considered working and good both, as it did not interfer with the symbol here. Maybe I am not using it right also. When I just now glanced at it, I was looking for the "text version" xml entity. Not finding that, it requires from me more information than a glance will give me.--RaboKarbakian (talk) 03:32, 6 October 2022 (UTC)[reply]
Hi. Not sure I follow. The intended uses is something like {{Text glypth|♈︎}} i.e. you would paste in the symbol (emojii or text either works). If you try to enter the xml or unicode codes it will not work (although I guess support for that could be added through a different parameter).
While alt text would be great having that generated automatically would require a huge lookup table which risks making the template fairly heavy. Since it's text it wouldn't be a proper alt text though (only works for images as far as I know), rather it would have to be displayed as a tooltip. /Lokal Profil (talk) 20:34, 12 October 2022 (UTC)[reply]
--RaboKarbakian (talk) 20:50, 13 October 2022 (UTC)[reply]
There is now support for that using an alt= parameter. ⚜︎ Lokal Profil (talk) 22:56, 19 October 2022 (UTC)[reply]

Some proofreading todos[edit]

The following are a list of my todos now that the text is proofread

Lokal Profil (talk) 23:12, 5 December 2022 (UTC)[reply]

Also. Figure out how to re-connect poems that are broken up by an image. (e.g. 474, 475 and 477) /Lokal Profil (talk) 22:36, 7 December 2022 (UTC)[reply]
I had a poem with images in the middle. A kindly hand replaced my problematic image placement, within {{ppoem}}, by using {{FI}} or maybe {{FIS}} -- which I personally have not used much because it had the same problems for me that {{img float}} had. {{ppoem has made so many many things simpler....--RaboKarbakian (talk) 23:24, 7 December 2022 (UTC)[reply]
Thanks for the suggestion and the example edit. Definitely looks like {{ppoem}} is the way forward here. Will just need to have a think about styles. I've done a better font size comparison now and it looks like the font size in the chapter starting poems is the same as in the in-text poems. In both cases the attached author names are the same font size as the poem, but in the chapter starting ones they are {{sc}}. So it should be fine to use {{ppoem|{fine}\n [...]}} everywhere. Lokal Profil (talk) 22:43, 9 December 2022 (UTC)[reply]
Have you got a link to the working example? Can't get it to fully work (only tried it in preview mode) Lokal Profil (talk) 23:11, 9 December 2022 (UTC)[reply]
Figured out a way of doing this using section labels. When transcluding one will need to do something like
<pages index="Star Lore Of All Ages, 1911.pdf" from="404" to="407" exclude="405-406" tosection="p293PrePoem" header="1" />
<pages index="Star Lore Of All Ages, 1911.pdf" from="405" to="406" header="0" />
<pages index="Star Lore Of All Ages, 1911.pdf" from="407" to="408" fromsection="p293PostPoem" header="0" />
/Lokal Profil (talk) 22:42, 16 December 2022 (UTC)[reply]

Transclusion todos[edit]

The index has been fully transcluded but the following should still be adressed:

  • Minor constellations should be checked and broken into subpages. This would involve moving images to the correct subpage and adding the subpages to the ToC.
  • Which contents are displayed on the basepage should be revisited. (Currently no ToC which might break book download, but adding it moves us away from how the source does it)
  • The Front matter subpage should get a Next parameter in the header. Contents may also be affected by the previous point.
  • There should probably be a page break between the first page of each section and the remaining content, see Ursa Major. Or this page could be excluded, if that is allowed?
  • Go through images and other objects using px or % sizes (when <80%) and consider using em Sizes instead.
  • Change inline {{spl2}} links to {{spl3}}.

The list above may be updated amended. / Lokal Profil (talk) 22:45, 26 December 2022 (UTC)[reply]

@JesseW, @RaboKarbakian: putting this questions to you first since you were kind enough to help out above.

  1. Does the ToC need to be included on the base page. And if so what is the standard approach to deal with the case when this does not correspond to the order in qhich it appears in the source?
  2. Do all pages need to be transcluded, in particular the section/chapter title pages e.g. p. 345 as seen in the top of the Ursa Major subpage.

/Lokal Profil (talk) 09:04, 30 December 2022 (UTC)[reply]

  1. The exporter (to epub, pdf, etc) includes everything that is linked to on "the base page". So for sure, including the index is the way to make the book function on ereaders. We make {{AuxTOC}} when there is no toc included in the printed book.
  2. Those pages. I don't mind them on my ereader, an announcement and a page flip for me. They look (my opinion) stupid in the web browser, atop the scrolling chapter; a little extra scroll for no reason whatsoever. I tend to include them mostly for "erring on the side of caution" as here, they try to include everything as it was. But, I don't think it is any great thing to exclude them. This is totally your call.--RaboKarbakian (talk) 15:15, 30 December 2022 (UTC)[reply]
    Thanks for the feedback.
    For 2. I'll probbly keep the pages then but add an explicit page break after it.
    For 1. What I'm unsure about is how to deal with Star Lore Of All Ages/Introduction where the ToC appears today (per where it appears in the source). My spontaneous impulse would be to break it out to its own subpage which would be linked through the header on Introduction but wouldn't get included in epubs etc. The issue with that becomes the list of Illustrations (today also on the Introduction subpage and in the source following directly on the ToC) which would be completely missing from the epub if broken out from the Introduction as it does not have its own entry in the ToC. / Lokal Profil (talk) 23:51, 31 December 2022 (UTC)[reply]
    @RaboKarbakian I added the ToC to the base page and removed it from Star Lore Of All Ages/Introduction. That page still contains some content which simply lies between the Introduction and the first Chapter. Not super happy with that solution but can't come up with anything better. / Lokal_Profil 16:59, 3 January 2023 (UTC)[reply]
    Lokal Profil I put all roman numeral pages on the Main page. I think I do that because I saw it done this way often and it also gets rid of other problems. An exception to this is when the Introduction parts are greater than the work, as was the case in at least one of the Aesop's Fables. The worst of this practice that I know of is the need to scroll through stuff to get to the index, but that is not so bad. Your solution looks fine. So, again, whatever you would like to do with that.--RaboKarbakian (talk) 18:26, 3 January 2023 (UTC)[reply]