* Website Tree Diagrams with Hyperlinks

[tatewise]

Yes, that should allow SVG-FTG to mimic whatever font is used elsewhere on the same web page outside the tree itself.

When experimenting with tree box width and height to get the best result for my chosen font I notice a strange effect.
Usually, with the Header options H W=80,H=80,MW=50,MH=50,BW=12,BH=12 there is a gap between the outermost boxes and the SVG border. But almost any change from W=80 or H=80 to say W=100 or H=90 destroys that gap and the boxes are either hard against the left & right border, or against the top & bottom border.

[ACProctor]

I would expect the lack of gap to always be true in the output when using Pan-Zoom. Could you send me a copy of your txt file, Mike?

Tony

[tatewise]

Here is what the SVG tree looks like and attached are the Tree.txt and Tree.html(zip) files.

SVGtree.png (27.95 KiB) Viewed 2873 times

[ACProctor]

That's another good one, Mike. The min-width/min-height properties are the main problem, and are not really needed so they can go. However, there's a more subtle problem to do with clash between Pan-Zoom's scaling and the initial/final margins that SVG-FTG plans for. I've fixed it but it meant changing header_iframe.html and so you may have to re-customise it when you see beta-2.

Obviously, the new FontFamily and FontSize settings will avoid the need for some of that header customisation but you probably still use your own background colours. These could be done via the XML registration file, which would make life easier for you.

Is anything else still being customised in the header?

Tony

[tatewise]

I think the only other header_iframe.html customisation I apply is to make the background transparent so the main web page background shows through the iframe:
<style>
div.tp-svg??inst?? {
display: inline-block;
background: none;
border-style: solid;
border-width: thin;

The other thing I do is enclose the iframe within text-align style to position it to left or center:
( < > replaced with { } to avoid FHUG Forum 404 error )
{div style="text-align:center;"}
{iframe src= ... onload="iframeLoaded(this);"}
{/iframe}
{/div}
So perhaps the Tree.txt file Header could have the following values for the Iframe= options:
Left, Center or Centre, Right and No to align the iframe.

[ACProctor]

I think it should be up to the hosting document (the one containing the iframe element) to position it, Mike. Although the size calculation in the PDF example for the hosting document has changed, it was the header_iframe.html of the embedded document I was interested in. Anything to do with CSS can be customised in the XML file rather than a special header file and I thought that might simplify things for your installation.

Tony

[ACProctor]

OK, I've managed to steal time away from the food, drink, and TV -- when no one was looking -- to package up a V6.2 Beta-2. The location is the same as before, Mike.

Couple of new entries added to the previous feature list:

1) The copy-and-paste features in the Tree Designer, and when bringing in elements from an imported GEDCOM file, were quite small-scale (i.e. multiple individuals, or a single family and their children). This has been extended with a 'Copy Descendants' option that copies a spouse-pair, their children, spouses of children, spouses of spouses, and so on down the generations. See "User Guide : Tree Designer", and "User Guide : GEDCOM Browser".

2) The standard font used in person-boxes was 13px Times New Roman. The only variation of this occurred when Small=True (which was also implied if Blog=True), in which case the font size was reduced to 10px. There is now explicit control over the choice of font style and size using the new header settings: FontFamily and FontSize. See "Program Notes : Configurations : Fonts".

Regarding the iframe support, both the Header_iframe.html file and the example iframe in the "Program Notes" document have changed. The calculation for resizing is a little more complicated and there is some explanation in that PDF document. As part of the effort to get the resizing to work correctly, responsibility for the border has also shifted from the embedded tree to the hosting iframe.

Tony

[tatewise]

Thank you for the updated package. It fixes the problem with the supplemental system application registration file.
However, I am still having issues with the iframe implementation as explained below.

Gap missing around tree
Regardless of the box header dimensions (e.g. W=80,H=80,MW=50,MH=50 ) there is now never any gap between the outermost boxes of the tree and the line border around the iframe. In fact, the bottom line border of the lowest box hides behind the bottom line border of the iframe. IMO it does not look at all pleasing to the eye.
See attached screenshot and Tree_1.zip file that contains the SVG HTML and the parent FH HTML.

Just displaying the Tree_1_SVG.html file without any iframe involvement similarly now has no gap around the edge.

I have tried experimenting with various border, margin & padding settings in the Tree_1_SVG.html file without success.

Iframe Background Color
There appear to be conflicting settings for the iframe background colour.

The Header_iframe.html file at about line 18 contains:
div.tp-svg??inst?? {
background: #f0f0f0;
border-style: none;

The SVG Program Notes 2.12 Iframe Usage gives an example iframe.text style containing:
background-color: lightgray;
border: 1px solid black;

The Header_iframe.html background setting takes precedence so the background-color style has no effect.
Perhaps background should be none like the border-style to allow the background-color to take control?

FontFamily
This works well up to a point, but only with a specifically named font.
If, as is popular, the FontFamily=sans-serif setting is used then the text size and wrapping is not so good.
The SVG User Guide should say what font values are expected for FontFamily.

Quite often website styles allow alternative fonts by setting font-family: Verdana, Arial, sans-serif
I appreciate that is probably not feasible for SVG-FTG due to the wrapping calculations.
However, might it be possible to support FontFamily=Verdana, Arial, sans-serif where the wrapping calculations are based on only the first font in the list?
It will also be necessary to 'hide' the commas in Verdana, Arial, sans-serif from the SVG Header syntax analysis.

FontWeight
Could FontWeight be added to the Header to set the font-weight: style?
I realise this may affect the wrapping calculations, which is why it needs to be a Header setting rather than a Header_iframe.html file edit to the font-weight style.

[ACProctor]

When sized to 'fit' then Pan-Zoom takes away all the gaps and the entities are up against the enclosing borders, Mike. You can set the initial zoom level to, say, 98% (as before) but that is lost when you select 'Reset'.

The overlap of the shape border and the iframe border seems to be a problem with the iframe border being inset rather than outset at the bottom. Setting an iframe 'padding: 1px;' fixes that here.

There are two background colours, Mike: the SVG one and the iframe one. I had originally made them different so that I could see whether there was any gap or not, but I can easily make them the same. If they're the same then an iframe padding:10px; will leave a gap, as you wanted.

The FontFamily sizing/wrapping is using font names from a Microsoft list and so I am constrained. Your suggestion of using the first one is good so I will think about the terminator issue.

Similarly with font-weight. I could implement FontBold=boolean (and similarly for italics) but not a numeric font weight. Is that any good?

Tony

[tatewise]

I will respond to those points in reverse order.

font-weight
Your suggestion of FontBold=boolean, FontItalic=boolean would work well for me.

Iframe Background Color
Perhaps the SVG Program Notes 2.12 Iframe Usage could explain the two background colour settings.
It is not so much that they need to be the same but that they exist and may both need changing.
e.g. In my use, I like the body background image to show through both the SVG and iframe by setting both to none.

Padding around tree
Your suggestion of adding padding:10px; to the iframe style does help, but there are still two issues for me.
When RESET, the bottom shape border is still hidden even though it is now separated from the iframe border by 10px.
When the tree is panned or zoomed the edges become hidden 10px before they reach the iframe border, which looks it bit strange to me.

I am convinced that in SVG v6.1 there was a gap between the outermost shapes and the border when RESET and the tree edges only became hidden when moved beyond the border. If necessary I can reinstall v6.1 to check my memory.

[ACProctor]

There was no iframe support in v6.1, Mike. The SVG border did not obscure the shapes then, and it doesn't now. What you're seeing is that the SVG border has now been replaced by an iframe border, and they are not playing as well together.

Have you tried turning off the iframe border? What about using iframe setting of 'padding:1px;' as I suggested?

The background colour can be copied from the embedded SVG tree, but you'll have to refresh my memory what your issue is with there being a background colour at all. You're the author of the iframe and so you can pick whatever colour you need.

Tony

[ACProctor]

Here's a quick example that asks for the background colour and sets it on the iframe.

This should be done in the same ifr_query() call, or at least in the handler part of it, because event handlers are single-threaded in JavaScript, and cannot execute until previous ones have completed.

Tony

[tatewise]

Yes, I am now happy with how the two background settings play together, but only after investigating the various files.
BUT the SVG Program Notes 2.12 Iframe Usage did not help me get there, because it does not mention the two settings.
That is what I would like to see improved; the documentation of the two background settings when working with iframes.

I don't like turning off the iframe border because I like some indication of where the tree will start being hidden rather it just disappears for no apparent reason.
I have tried various 'padding:1px;' settings up to 'padding:10px;' which increase the gap between the SVG frame and the iframe but does not reveal all of the border of the bottom boxes when RESET is applied. If the tree is then zoomed or panned up then those bottom border lines become thicker. Can you repeat that symptom?

Regarding, the border/gap/padding around trees, I have gone back and reinstalled SVG-FTG v6.1 to check my memory.
To clarify the terminology, when I say 'border' I mean the thin solid black rectangular line drawn around the whole tree, or drawn around each tree box shape.
The 'gap' is the background coloured area between the shape borders of the outermost boxes and the whole tree border.

This is a non-iframe SVG tree with v6.2 Beta-2 and has NO gap when first displayed and is the same after using RESET.
It does not matter what box W= or H= values are used there is never any gap.

SVGtree v6-2 Beta-2.png (24.94 KiB) Viewed 2683 times

This is the same SVG tree using v6. 1 and does have a gap around the tree when first displayed, although the gap on each side does vanish after using RESET, but a gap top & bottom is retained.

SVGtree v6-1.png (28.73 KiB) Viewed 2683 times

If I choose box W=80 instead of W=122 used above, then the first display is similar with a gap all around, but after using RESET the gap top & bottom vanishes, but a gap on either side is retained.

It is the total loss of that gap in v6.2 Beta that I don't like much, and was not keen on the partial gap loss in v6.1.
Is it possible to retain a gap all around the tree even after a RESET regardless of box W= and H= values?

[ACProctor]

In the V6.1 HTML file, Mike, if you look for the Pan-Zoom initialisation, you'll see that the initial zoom level was 98%, and that left a margin. However, a RESET lost that and I had complaints about it. Try as I did, I could not find a way of making the RESET go to a specific zoom level that was < 100% and so I had to leave it at an initial 100%.

Re: other issues, FontBold and FontItalic done. FontFamily will be a |-separated list. SVG-FTG will also traverse the same list looking for a loaded font to use for sizing.

Tony

[tatewise]

Re: other issues, they look like excellent solutions.

Regarding the margin and Pan-Zoom in iframes, I have stumbled into a near-perfect solution.

If the following style setting is added to the header.html file so it appears in the Tree.html file then:

• There is a small margin gap around the SVG tree inside the iframe;
• When RESET is used, it restores exactly the same margin gap;
• When the tree is panned up/down it moves into the top/bottom margin gap before becoming hidden;
• Unfortunately, when panned left/right the margin gap is not used and the tree edge is immediately hidden;
• It does not seem to matter what Header settings are used for the W= H= MW= MH= values, it still works;

So apart from the panning left/right not using the margin gap, it is absolutely perfect.

The style is added to the body section after g id="tp-pz-svg" where the text { } style exists:

Code: Select all

div.tp-svg {
	width: 96%;
	margin: auto;
}

I don't understand why it works nor why the panning left/right doesn't use the margin gap. Maybe you have some ideas?

[ACProctor]

Mike, could you try an experiment there? In the wrapper function that configures the pan-zoom, could you add this line at the end?

Code: Select all

window[pz].reset = function() {  window[pz].center(); window[pz].zoom(0.95); }

This will try and modify the action of the reset control. There is no public API for this but if it works then I'm going to use it.

Tony

[tatewise]

Tony, that works perfectly whenever RESET is clicked.
The SVG tree is centred with a gap all around, and panning the tree uses that gap before hiding the edges of the boxes when they are outside the iframe border.

However, when the web page is initially opened or refreshed, the SVG tree fills the iframe without any gap all around.
So, is there a way to invoke the RESET when the web page is opened or refreshed?

[ACProctor]

I think that should be easy, Mike. This was just an experiment to deal with the 'Reset' control, but I didn't add any initialisation code to set the same zoom level. That used to be there but I'd removed for the reasons I mentioned, but it can be added back now.

Looks like we have a plan

I would like to release the proper 6.2 before end of the year, unless some other issue pops up.

Thanks for your input here, Mike. It should enable SVG-FTG to be usable in more scenarios.

Tony

[tatewise]

That sounds excellent.
I forgot to mention that the RESET works fine went the SVG Tree.html is used on its own, i.e. not embedded in an iframe.

[ACProctor]

V6.2 now released to usual place, Mike, and associated blog post published. See https://parallaxviewpoint.com/SVG-FTG/ for summary information.

As before, both the Header_iframe.html and the example iframe element in the documentation have changed. They should be simpler now that I've sorted the last of the sizing issues.

The blog post for V6.2 gives the paths to the relevant topics in the PDF documents. You've seen most of the features already but there were a few newer ones that were waiting on testing:

• New 'All Settings' form in the Tree Designer -- some other developers didn't like the standard forms that tried to use logical grouping of settings, so this tabular format of every single one might be more familiar to them

• PanZoomFit setting. This controls the margin when the Pan-Zoom library is set to "fit: true". The default is 95% (i.e. zoom out slightly). You might want to tweak this if you need a bigger margin.

• Flicker-free scrolling in the Tree Designer. This has been a long-standing issue that needed a re-write.

Tony

[ACProctor]

Re: localisation of Pan-Zoom, there's a new link in the "Program Notes : Pan-Zoom" section that shows how to disable the standard controls and put your own ones in place. As I said before, the standard ones are not using text and so are virtually impossible to localise. The demo at that link only uses simple square buttons, but it's a pointer in the right direction.

They skip over the fact that the controls must be immune from the pan and zoom, and that means carefully placing them in a different <g> (Pan-Zoom creates some invisible ones and pushes your SVG content into one so that it can be 'transformed').

Tony

[ACProctor]

One final update on this thread, which is otherwise dormant now: if you're not in the SVG-FTG Group on Facebook then you may not be aware of the forthcoming support for drop-shadows on boxes, 3-D boxes, fancy picture frames on boxes, or elliptical boxes.

This was me finishing some old experimentation, but all now work using a single enhancement. There are pictures in the Group demonstrating some of these special effects.

Mike, would they be of interest within this add-in, or are you trying to keep it consistent with FH?

Tony

[tatewise]

There are several different potential uses for SVG-FTG that have been discussed in this thread.

Some may want to create 'large' tree diagrams for websites using any of the features including the latest additions as an alternative to FH tree Diagrams.

My interest is in adding 'family group' tree diagrams to FH generated websites via my Improve Website or CD DVD HTML plugin that may need to limit the options to a small subset. However, such FH websites are predominantly text-based.

So neither of those uses are particularly constrained to be consistent with FH tree Diagrams.

[ACProctor]

That's not a problem, Mike. The enhancements won't appear until SVG-FTG V6.3 anyway, and so there's plenty of time to let users try your add-in first.

My main reason for mentioning these special effects is that you have full control over your header file, and so you could provide any of them for your users with virtually no effort.

Tony