Bug: Linking to self-referencing PageVolume milestone in PBB?
I'm continuing to play with the PBB.
This time, I wanted to tackle something a bit bigger. I wanted do build on the work done by other Logos users and combine the two volumes of Fairbairn's Typology of Scripture into a single file (see original post).
The main reason I wanted to combine the two volumes is that the indices at the end of vol. 2 pointed to both volumes, and I wanted to try my hand at linking to those page numbers.
So, first I changed Page milestones to PageVolume milestones, so that [[@Page:17]] in volume 1 would become [[@PageVolume:1,17]] in the combined file.
The problem came when I wanted to link to specific milestones. I tried [[i. 17 >> PageVolume:1,17]] and that did not work. The only way I could get the links to compile correctly was to explicitly state I wanted to open the PBB file: e.g., [[i. 17 >> logosres:pbb:7adb1c4ab964400fb6aa72c155494968;ref=VolumePage.V_1,_p_17]]
Comments
-
I forgot to mention. I've included a copy of the file I've been working with as a zipped attachment.
0 -
Jim Darlack said:
So, first I changed Page milestones to PageVolume milestones, so that [[@Page:17]] in volume 1 would become [[@PageVolume:1,17]]
I note you use the correct datatype VolumePage in the document.
Jim Darlack said:The only way I could get the links to compile correctly was to explicitly state I wanted to open the PBB file: e.g., [[i. 17 >> logosres:pbb:7adb1c4ab964400fb6aa72c155494968;ref=VolumePage.V_1,_p_17]]
As an alternative make each milestone a Bookmark in Word and make your reference a hyperlink to that bookmark (you can change the Hyperlink style so that it does not contain the underscore).
EDIT: [[Page:x]] always refers to pages of the current resource. [[VolumePage:x,y]] may refer to other resources but I don't know why Logos do not use the current resource as a default.
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
As an alternative make each milestone a Bookmark in Word and make your reference a hyperlink to that bookmark (you can change the Hyperlink style so that it does not contain the underscore).
But that really shouldn't be necessary. I had a go at this last night, and couldn't find a syntax that worked. If you can't link to a specific Volume/Page, then I would consider that a bug. I haven't filed a bug report simply because I hoped someone else might chime in with the right syntax.
Jim Darlack said:The only way I could get the links to compile correctly was to explicitly state I wanted to open the PBB file: e.g., [[i. 17 >> logosres:pbb:7adb1c4ab964400fb6aa72c155494968;ref=VolumePage.V_1,_p_17]]
You shouldn't do this, because the resource ID is randomly generated, so this won't work on anyone else's build of the PBB.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
But that really shouldn't be necessary. I had a go at this last night, and couldn't find a syntax that worked. If you can't link to a specific Volume/Page, then I would consider that a bug.
I think that a VolumePage datatype link should be recognised within the current PB, as happens with Page e.g.where one docx file is one volume of the PB. But you can't manage a generic datatype across different resources/PB's e.g. TDNT has a unique datatype for its Volume/Page, but we can't create datatypes.
Dave
===Windows 11 & Android 13
0 -
Mark Barnes said:Jim Darlack said:
The only way I could get the links to compile correctly was to explicitly state I wanted to open the PBB file: e.g., [[i. 17 >> logosres:pbb:7adb1c4ab964400fb6aa72c155494968;ref=VolumePage.V_1,_p_17]]
You shouldn't do this, because the resource ID is randomly generated, so this won't work on anyone else's build of the PBB.,
There's a clunky workaround with this, I imagine. Basically, someone would have to install the version I put together, and then find the resource ID by looking at the information for the book after it's compiled. Then they'd have to go into the docx. and find and replace all of my old ID's with the one that their iteration of Logos created.
0 -
Dave Hooton said:
I think that a VolumePage datatype link should be recognised within the current PB, as happens with Page
It must do. And if it doesn't, that's a bug.
The problem is that Page and VolumePage are datatypes. Therefore, using them requires datatype links, not resource links, to use the jargon from the Wiki page. However, they're special datatype links in that they always refer to the current resource, whilst all other datatype links could refer to any resource, and therefore they're converted into links at compile time. Logos has ensure that the Personal Book builder recognises that Page is a special datatype link, but I'm not sure they've done the same for VolumePage. In fact, according to the Wiki, there should be four datatypes treated in this way (although as I made that edit, it may not be correct!).
Dave Hooton said:TDNT has a unique datatype for its Volume/Page
That was an old design decision, that I'm sure wouldn't be made today. That datatype was added to other lexicons to, to allow them to scroll with TDNT, or to pop-up when you clicked on TDNT link even if you didn't own TDNT (specifically DBL and ESL). If it was up to me, I'd remove it altogether. It creates real confusion in prioritisiation.
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:
It must do. And if it doesn't, that's a bug...
Yes... [wondering why you need to re-state what we both understand]
Dave
===Windows 11 & Android 13
0 -
Dave Hooton said:
Yes... [wondering why you need to re-state what we both understand]
Because I'm still hoping that Logos will see this, and I want it fixed!
This is my personal Faithlife account. On 1 March 2022, I started working for Faithlife, and have a new 'official' user account. Posts on this account shouldn't be taken as official Faithlife views!
0 -
Mark Barnes said:Dave Hooton said:
Yes... [wondering why you need to re-state what we both understand]
Because I'm still hoping that Logos will see this, and I want it fixed!
Perhaps an email to Bradley—or some other appropriate person @ Logos—might help
0 -
Does anyone know if this bug ( VolumePage linking) has been solved yet? I can't see any mention of it. [:(] . I know I can do simple work rounds to get a direct linking but it would be nice to be able to use it. I am creating a volume of research papers each with their own page numberings....
0 -
JohnB said:
Does anyone know if this bug ( VolumePage linking) has been solved yet?
As Logos haven't visited this thread we can assume they are ignorant of the bug.
Dave
===Windows 11 & Android 13
0 -
Ah well!. That's life.
Thanks Dave
0 -
This should be fixed in the next release; the syntax [[i. 17 >> VolumePage:1,17]] will create a link to a Volume/Page milestone in the current resource.
0 -
GREAT!
I can start tagging now!
Thanks
John
0 -
Bradley Grainger (Logos) said:
This should be fixed in the next release; the syntax [[i. 17 >> VolumePage:1,17]] will create a link to a Volume/Page milestone in the current resource.
This should be fixed in 5.2b Beta 1.
0 -
Angela Murashov said:
This should be fixed in 5.2b Beta 1.
Good news - VolumePage jumps now work in my multi-volume PB (in beta).
Dave
===Windows 11 & Android 13
0 -
Dave, I am not part of the PC beta program and I doubt VERY much if you have an answer but is there any hint when 5.2b is out, we are till on 5.2a (SR-6 to be pecise). I have several large files nearly ready to be placed on a Faithlife group using VolumePage and I am not sure whether to use bookmarks to link the contents page or hang on till 5.2b goes post beta and use the VolumePage linking.
0 -
JohnB said:
is there any hint when 5.2b is out, we are till on 5.2a (SR-6 to be pecise). I have several large files nearly ready to be placed on a Faithlife group using VolumePage and I am not sure whether to use bookmarks to link the contents page or hang on till 5.2b goes post beta and use the VolumePage linking.
John,
for what it's worth, Dylan introduced the current 5.2b beta with the (quite unusual) remark that the beta cycle will be short: http://community.logos.com/forums/p/84676/593888.aspx#593888 and from what I see in the forum, no real big issues have been brought up (what looked like such all has been fixed very quickly). This still is no indication - after all, the next bug report could throw it off the rails - but it might be really soon.
Have joy in the Lord!
0 -
NB.Mick said:
from what I see in the forum, no real big issues have been brought up
Unfortunately, we ran into some unexpected problems with network connections in mono (on Mac) that are a severe blocking issue. Even more unfortunately, it isn't something we've been able to reproduce in-house, so we can only know for sure that it's fixed if we stop getting crash reports from the field. Fortunately, we believe we've identified a fix in mono that we'll be including in the next beta (cf. https://github.com/LogosBible/mono/commits/3.4.0-logos).
TL;DR: this beta cycle is taking longer than we originally anticipated.
0 -
Bradley Grainger (Logos) said:
so we can only know for sure that it's fixed if we stop getting crash reports from the field.
Then, I will be sure to report them all at least once per crash [;)].
0 -
Bradley Grainger (Logos) said:
this beta cycle is taking longer than we originally anticipated.
Thanks for the info although it was not what I was wanting to hear!
0
