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]]

fairbairn-vols-1-2.zip

Find more posts tagged with

Comments

Jim Darlack

I forgot to mention. I've included a copy of the file I've been working with as a zipped attachment.

Dave Hooton

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.

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.

Mark Barnes

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.

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.

Dave Hooton

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.

Jim Darlack

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.

Mark Barnes

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!).

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.

Bradley Grainger (Logos)

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.

JohnB

GREAT!

I can start tagging now!

Thanks

John

Angela Murashov

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.

Dave Hooton

This should be fixed in 5.2b Beta 1.

Good news - VolumePage jumps now work in my multi-volume PB (in beta).

JohnB

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.