* Website Tree Diagrams with Hyperlinks

[ACProctor]

Sorry, Mike, that would be width-div, etc. for the example I provided. For instance, just after the head element:

Code: Select all

<!-- FH width=??width-div?? height=??height-div??-->

Tony

[tatewise]

I understand your suggestion for extracting width and height.

However, I cannot get the SVG tree frame to fill the viewport, the same as the original problem.
I am using the default installed Header_px.html file that contains:
width: ??width-div??;
height: ??height-div??;
max-width: ??width-max??;
max-height: ??height-max??;
min-width: 40vw;
min-height: 40vh;

Then I'm using your TreeImage.html technique. I have attached the FH and SVG HTML files below in ZIP format.
This is what gets displayed, and I cannot get rid of the large grey part of the iframe viewport below the SVG tree.

The attachment iframeD.png is no longer available

[ACProctor]

I see now what you're saying, Mike, but I don't get this on my examples, which is really odd. There's something different about your code but I cannot see it.

I added an onload handler to the iframe to shrink the height, and it did (after moving the default W/H from CSS back into the iframe attributes so they could be overridden), but there still something extra below the SVG frame. Invoking the SVG file on its own doesn't show it. I tried removing the Compendia and "program data" elements from the bottom (which should all be invisible anyway) but it made no difference.

Tony

[ACProctor]

Do you have the *.txt content so that I can run it through V6.2 to see if that's the difference?

Tony

[tatewise]

Yes, it is attached.

I've pruned down the Tree_1_FH.html file until there is nothing left except the iframe.test style in head section and the iframe... in the body section and it still has the grey area below.

[ACProctor]

It's the max-height being set as a number of vh units less than 100vh, Mike. This is trying to preserve the aspect ratio but it's not really helping in this scenario.

My copy was in a test state and I had forgotten. I'm looking for a better magic spell at the moment.

I'm also looking for a way to get the SVG frame W/H programmatically rather than having to scan for them. The values are stored in an 'nd_dims' array in V6.2 but trying to get them from the parent document runs into cross-origin violations, especially if running on the local file system.

Tony

[tatewise]

Yes, as I said yesterday, removing the max-height: ??height-max??; line from my custom Header.html file works.
Equally, max-height: 100%; seems to work as well.
Those work even when the SVG Tree HTML file is rendered on its own, so I'm not sure why aspect ratio preservation is needed.

[ACProctor]

It avoids smaller frames bring stretched. Remember that is sizing the enclosing div.

Tony

[ACProctor]

Mike, since we seem to be getting somewhere, can be agree on a possible plan?

1) I will produce a Header_iframe.html that produces the best rendering we can find for arbitrary trees (i.e. ones that may include apps). I welcome your input here.

2) A small communication mechanism allowing the outer document to ask the inner (tree) document for the SVG frame size. This will avoid the need for you to go searching for it. This must also work cross-origin and for file: schemes.

Clearly I want to make these items as general purpose as I can.

You would still be able to produce a variant of this new header, and use the SVG frame size to generate a better-sized iframe for your application.

Tony

[tatewise]

1) Yes, OK. What input do you need?
2) Yes, OK.
For the iframes there is a working solution using a custom header and searching for the width/height is trivial for the plugin and I've already written the script that does all that.
I accept would be nice to make it all neat and tidy but is it really necessary. Are there more pressing issues?
Like the ones I discussed before...
Being able to assign an application to different buttons.
Being able to change some rigid text that is currently inhibited despite associated Tooltip text being customisable.
e.g. TooltipTL for Compendia can be customised to say anything, but the text in the popup box of links cannot!

[ACProctor]

I accept would be nice to make it all neat and tidy but is it really necessary. Are there more pressing issues?
Like the ones I discussed before...
Being able to assign an application to different buttons.
Being able to change some rigid text that is currently inhibited despite associated Tooltip text being customisable.
e.g. TooltipTL for Compendia can be customised to say anything, but the text in the popup box of links cannot!

For me, yes. Integration with other software is a goal that needs some work.

Assigning apps to different buttons, changing that Compendia text, adding new apps, etc., can all be done at the moment with a second XML file. Look for "modifiers" in the 'Program Notes' document.

Tony

[tatewise]

Tony, I have designed an application derived from Compendia that does exactly what I want.
To support that I have an ApplicationsServicesFHW.xml file that works fine when saved in C:\Program Files (x86)\SVG

Would it be possible to enhance the Tree.txt file Header settings to allow Applications="ApplicationsServicesFHW.xml"
i.e.
In the same way that Header="header.html" substitutes the C:\Program Files (x86)\SVG\Header.html
then Applications="ApplicationsServicesFHW.xml" would supplement the C:\Program Files (x86)\SVG\ folder.
That then avoids the user having to add it manually and as a bonus during development, it makes it easier to make rapid changes to the ApplicationsServicesFHW.xml file without continually updating the C:\Program Files (x86)\SVG\ folder.

[ACProctor]

No, they're picked up automatically, Mike. As long as the filename matches the documented wildcard then it loads it. Nothing else is required.

Tony

[tatewise]

Sorry, you are missing the point Tony.
I am trying to avoid installing the customised ApplicationsServicesFHW.xml file into the C:\Program Files (x86)\SVG folder, which may be Administrator protected on the FH plugin user's PC. I want to avoid creating an installation package or instructing the plugin user to install the ApplicationsServicesFHW.xml file into the C:\Program Files (x86)\SVG folder.
I would like the end user to simply install the standard SVG-FTG application and then download and run the plugin without any further complications. It would be neat if a Tree.txt file Header setting like Applications="ApplicationsServicesFHW.xml" would work similarly to Header="header.html" and treat the ApplicationsServicesFHW.xml file in the same way as if it were located in the C:\Program Files (x86)\SVG folder.

[ACProctor]

I'll see what i can do, Mike. I do take your point on a number of issues but it feels like re-inventing the wheel to some extent. Leave it with me, anyway.

As for the iframe stuff, I have a really neat solution that is easy to deploy. I wanted this to be clean because I can see it being important in other scenarios if SVG-FTG ever gets better known.

Its problem has always been that it doesn't fit the normal mould of an online or desktop genealogy product that has a database and data-entry tools -- it has always been more about presentation and end-user (i.e. extended family rather than genealogists) functionality.

Tony

[ACProctor]

As I said, Mike, I'm working on other stuff this week, but I want to add a note about my future direction (some of this has already been experimented with).

1) I have moved the Compendia caption from HTML into a named variable (cp_title), which does make it easier to change, but you still need an XML file. This is already there now.

2) I have a "service" for parent-to-iFrame communication. This also works with the file: protocol and I have an example that asks the tree for its width and height, and then modifies the iframe size.

3) A new header setting (Iframe=True) includes this service, selects a few other settings, and uses a new Header_iframe.html (unless you have a customised one).

4) A new header setting ValidOrigins is a list of "origins" (e.g. https://example.com) that the tree side of the communication service will expect. This is strongly recommended to prevent unauthorised software manipulating your trees via an iframe.

5) Yet another header setting, AppSrvFile implements your suggestion of a local supplement to ApplicationsServices*.xml. It is important to note that this is per-tree as it is a header setting, and so can be applied selectively to different trees; the standard XML files apply to all trees. I decided to go with your suggestion, even though it was a bit tricky, because it has value when developing new applications.

Now the bad news: this all means that the beta can't be ready today. I'll try and aim for end of the week but let me know if that's messing you up.

Tony

[tatewise]

It would be extremely useful if the ApplicationsServices***.xml file could be more dynamic like the header.html file.
The more I look at its features, the more I find that may need changing dynamically in response to plugin user options.
e.g.
1)
In the ApplicationsServicesFH.xml file, there is exi_show(ev,type,inst,key,false) where the last parameter may be true or false depending on whether links are to open in the same webpage or a new webpage. That choice may be a plugin option chosen by the plugin end-user. Needing to install a different XML file into C:\Program Files (x86)\SVG\ each time they change that option would be an annoyance.
2)
I've designed an ApplicationsServicesRel.xml file like Compendia and in the <Postamble> there are fragments such as:
'rel_hdr' Choose relative button title='Close the list' on click Close
where those words may need translating to a foreign language used on the webpage and chosen by the plugin end-user.
Needing to install a different XML file into C:\Program Files (x86)\SVG\ for each language would be an annoyance.

Can you suggest any other way of dynamically making those types of end-user changes?

BTW:
The pan & zoom feature has a RESET control in the bottom right corner.
How could that be translated into a foreign language similar to point 2) above?

[ACProctor]

I've published the first V6.2 beta for anyone who might be interested. Available at: https://www.dropbox.com/sh/14orkuhw58fj ... -j9Ja?dl=0

NB: Installing this will displace your existing version and you'll need to re-install it when you've finished with the beta. If you don't want to take part in the beta then you can still download the kit and browse the documents. Here's a list of highlights for new or modified sections:

Private and Living Persons
See "User Guide : Hiding Selected Persons".

Tabbed Content in Notes
See "User Guide : HTML Editing : Tabbed Content", and "Program Notes : Tabbed Content".

Customising Applications
See "Program Notes : Application Development : Header and Trailer Code".

Local tree-specific registrations files
See "Program Notes : Application Development : Application Registration".

External-Information Application
See "User Guide : Applications and Services : External Information".

Automation
See "User Guide : Command-line and Shortcuts".

Iframe usage
See "Program Notes : Configurations : Iframe Usage".

Image Errors
See "User Guide : Tree Designer : Person Images".

Note: There's a new item on the right-click menu in the Tree Designer (copy and pasting of descendant subtrees) which is not finished yet, so don't worry about it for now.

[tatewise]

Wow! Thank you Tony.
I've used several of the new features successfully, such as iframes and the command-line -L -M -P -X options.
It is all working as expected.

There is one 'snag' that I've run into with supplemental system application registration files.
I use a Tree.txt file with a Header 'H AppSrvFile=E:\...\ApplicationsServicesRel.xml,Relatives=True'
SVG complains about an 'Unknown setting in header record: Relatives' where that is the application id, because it does not load the local registration file until after parsing 'Relatives=True'.

Here is the segment of the SVG log:
Loading tree definition file: E:\Family Tree CD or DVD\data files\Tree_1_SVG.txt
File character set: ANSI (terminators CRLF)
Unknown setting in header record: Relatives
Loaded 7 persons and 3 families from file
Loading local registration file: E:\Family Tree CD or DVD\data files\ApplicationsServicesRel.xml
1 applications, 0 services, and 0 modifiers were loaded

If I copy the same supplemental system application registration file into C:\Program Files (x86)\SVG\ then it all works fine, because that supplemental file is loaded much earlier.
What am I doing wrong?

[ACProctor]

Ah, good one. Thanks Mike.

Re: your past question about the pan-zoom library being localised, I looked into this before and it does not use text. It carves the "RESET" itself using a path element. I have no idea why.

There is an issue raised for it on GitHub but I suspect I'm going to have to fix it myself one day. Nasty!

Tony

[ACProctor]

Does anyone else expect to have feedback on the beta such that I should wait before V6.2 is released properly?

I was hoping to publish it before Christmas, which I know is a short beta but most of the recent stuff was for Mike's plug-in.

Tony

[ColeValleyGirl]

I haven't got time to look at it, I'm afraid, Tony.

[tatewise]

Tony, will your published version fix the 'snag' I reported last Thursday with supplemental system application registration files?

[ACProctor]

Yeah, I just had to switch two lines, Mike. A silly bug on my part

Tony

[ACProctor]

I know it's close to Christmas, Mike, but I knocked up a reliable algorithm to size a piece of text in an arbitrary font, and wrap it neatly over lines of a given pixel width. As I said before, this has to be done within SVG-FTG (i.e. offline) so that I can place the individual text segments inside the SVG output -- SVG does not wrap text itself.

I'm toying with the idea of waiting a bit longer before releasing V6.2 and including this. There's about a a day's work needed to put it in SVG-FTG, but if I'm going to advertise it in the release notes then I should really issue a beta-2.

Would you be interested?

Tony

P.S. Happy Christmas to everyone.