I am not sure what I am doing different but my plotly graph does not scale like that.
Steps
this is what I see…
Tom
Here is my sample file I am using…
Workout Repcount processing.tbx (548.7 KB)
What note are you previewing? What do you want us to look at, your test file seems smaller (filesize) than the original.
FWIW, I think posters were intended to be viewed in the view pane of map view but here, from your file, is poster note “Agt- Workout Data” in the preview sub-tab of the Text pane—so visible in both panes:
Ahhh… I was looking in Outline view at the text pane with htmlExportTemplate that has worked in many examples except this one. Viewing in Map view, it works perfectly. I had not used Posters very much in the past. Paul’s recent example, made me think of some of my own use cases I need to try as well.
Thanks
Essentially, a poster—IIRC, by intent, is a special form of map view image note. In the case of a poster, the ‘image’ is rendered as the HTML export of the note. Although a number of posters might share a common poster, it is highly likely a poster does not use a vanilla built-in HTML template as poster content will need to call on† the likes of JavaScript libraries etc., that an ordinary HTML page doesn’t use.
However, if you have several poster notes using the same JavaScript code (libraries) they might safely use the same template.
Your screen grab of the a note in preview—where the view is Map view—does look like an unexpected outcome. This is not a bug because, as noted, posters were conceived of as a feature for Map view: IOW, behaviour in other possible views, Preview included, wasn’t envisaged/tested.feature.
However, it seems odd that the Text pane preview renders correctly if the view pane uses map view but not for other view types. Your screen grab suggests that the text pane preview fins the correct data except the height/width of the ‘image’ to show. IOW, except in a very narrow text pane, preview might show the image albeit with scroll bars.
†. Before I’m corrected, yes you could put the <script> calls in the body ($Text) of the note rather than in the <head> using the template. But, the overarching point holds: if using posters you’re likely going to need to make a template not needed by non-poster notes.
If you want to embed (say) a Plotly image in an HTML view in the preview pane, that’s easy enough: it is, after all, the intended use of Plotly!
To explain in more detail, the poster-in text-preview method doesn’t work (correctly) for all views. In @TomD’s file, with container /Agt- Workout data/ and the tab using Outline, Chart, Treemap view—in fact any view other than Map or Timeline you get this:
…or some thing like it (the poster size varies by view-pane type but is never correct except for Tabs using Map or Timeline view). It appears the preview pane is unable to read, or doesn’t use, the height/width used in map view and which is needed to render the poster correctly.
With the view pane in Map our Timeline you get the correct outcome as illustrated in the screen-grab in my post #7 above.
As stated, I don’t think this is a bug so much as fallout from an unstated assumption (limitation) that posters would only work/be used in the view pane using map view, and thus a failure to explicitly test—until now—posters in text pane preview of tabs not using Map view in the view pane.
Looking at the ‘bad’ renders above, it looks to be a case of ensuring Preview (regardless of view pane type) is able to access the the map view ‘icon’ size in order to render the post correctly in preview. The fact that timeline+preview does do this correctly (why only this view type other than map?) suggests other views ought to be able to do the same but perhaps simply are not connected up to do so.
Doh! Investigating this with @satikusala, he spotted the ‘error’. The template used by container ‘Agt- Workout data’ is called ‘Plotly’. It uses $ScreenHeight and $ScreenWidth to set the size of the poster, within the ‘screen’. In a map view, the map is unbounded, so you need to say how much of the map (screen) you wish to use. Even in the Text/preview pane, the latter looks to the view pane for the ‘screen’ so it works in the text pane.
Now consider Outline view. Notice how the ‘height’ of the preview is the same as the height of the source record in the view pane:
So the poster in the preview pane would like to be taller but the view pane ‘screen’ is a max c. 16 points tall. So there is an accidental vertical constraint. Using posters within some of his reports, @satikusala sets a literal size. In the latter context, there is a lot of page structure in the template that likely sets a more explicit base ‘screen’ size.
But using a ‘bare’ poster in a tab not using Map view† in the view pane, the problem is the screen/map is different from that of the map view. I’m not sure is user code can navigate around this or whether we need some way for the template to signal to use a map-scale screen even when the active tab’s view is not a Map.
I’ve tried fiddling with the poster (‘Plotly’) template and setting a page size, but to no avail (when using in text/preview of a tab using outline view).Definitely not a bug, but rather it is an interesting outcome from using a feature in an unenvisaged way.
†. Re-testing with a timeline view tab also shows the poster wrong size—clearly I’d changed the timeline settings a bit from my previous test. All non-map views ‘failing’ to render the poster the correct size now makes sense…
I think you simply need to do one thing for Preview: make sure the div is the size you’d like. In the poster template, we have:
<div id="tester" class = "plotly"
style="width:^value($ScreenWidth)px; height: ^value($ScreenHeight)px;"></div>
Replace $ScreenWidth and $ScreenHeight with appropriate constants in the preview template,
Yes, this is what I do.
I think this misunderstands the problem.
If I hardset the div’s height/width for the preview pane the poster looks all wrong in the map view. I’m looking for a solution that lets you define a poster and also be able to preview the same content in other views.
Turns out the reported (read-only) $ScreenHeight/$ScreenWidth for the same note are different depending on the view type used in the view pane. So in a map view tab I see 594 / 368, but the same note in an Outline view tab, the same attributes show 783 / 23.
Essentially, the scenario needs all view types to read the map view’s ‘screen’ width/height. Action code doesn’t let me read the map view’s $ScreenHeight/$ScreenWidth so I can set those as the div’s size in other views.
Hard-setting the values here
<div id="tester" class = "plotly"
style="width:^value($ScreenWidth)px; height: ^value($ScreenHeight)px;"></div>
solves a different scenario than the one I’m describing and also makes the poster looks odd in map view. Instead I want the poster to look the same in the map view and in the preview of any tab regardless of the tabs view type. This means the poster can be accessed in other tabs via the preview. Otherwise, every time the poster is altered in map view the $ScreenHeight/$ScreenWidth have to be checked and manually edited into the template which seems a bit clunky.
Do non-Map-view text panes actually have a use for a different $ScreenHeight/$ScreenWidth. How does the different screen size per view type aide the user in their work?
I envision you’d normally use a different template for Preview and HTML export than you’d use for the poster. The poster says “size this div to fill the poster area”. The Preview or HTML view template would say, “size this div to three inches high and five inches wide”.
What follows isn’t by way of making an argument for argument’s sake, I do feel something is being missed here. There is a ‘TL;DR’ summary at the end.
Whilst this makes sense in general …
… the reality is that many never export HTML yet nonetheless use preview to see their notes in ‘rendered’ form. Why they choose to do so is not the point: they do so. Whilst for long-time users of Tinderbox may intuitively think that 'Preview' == preview of the exported HTML, I don’t think that is the general understanding. I’d observe it isn’t the case for those users just beginning to dig into features like posters.
A poster note is likely using both the ‘Poster’ prototype and a (export) template for that poster—possibly each poster has a different template. However, a note can only have one assigned template† which encapsulate’s a false assumption, that preview only has one use context. These days, I think that is not a supportable premise. Also many users want to ‘just’ use something like preview having to do lots of prior work. The implication of the latter I’ll enlarge on below.
If I make a poster (correctly!), it looks fine in Map view. It also looks fine previewed in that Tab’s text pane preview, though there is little point in that given that I can see the poster in the view pane (but, I might want to see the poster (right pane), in context to a different part of the map (left pane).
Now, switch the view pane to any other view type and we have a problem. We can’t see the poster in the Preview as the read-only [sic] $ScreenWidth/$ScreenHeight differ depending on the current tabs’s assigned view type. I can’t the see the point of that as AFAICT the only application of these attribute values is for poster use. IOW, I’d suggest their values should be—regardless of current view type—the current (poster) note’s size in map view. Then the problem goes away.
Otherwise, the user must, but only whilst view pane is in map view, save $ScreenWidth and $ScreenHeight into user attributes and then use those values in the poster note’s template. Worse, if subsequently the poster size is altered, the saved width/height must be manually updated whilst in map view, otherwise $ScreenWidth/$ScreenHeight. That’s a lot of niche behaviour to remember for a user who wonders why the post doesn’t 'preview when using, of example, Attribute Browser view.
I suspect the per-view-type $ScreenWidth and $ScreenHeight being per view type, rather than the same value regardless of view type, is an accident of birth. As $ScreenWidth and $ScreenHeight are not, AFAICT, used except in Map view their seems little point in read-only system attributes being bound (for calculation of values) to the tab’s current view type. Ergo, unintentional hilarity ensures.
TL:DR binding read-only $ScreenWidth and $ScreenHeight to the current view rather than the map view poster size offers what specific gain to the Tinderbox user?
†. Before it’s pointed out, it is true that one can route around this via ^include^ and the like. But that requires some Tinderbox action/export coding expertise, and this is about ordinary users not experts.
OK. The poster template might use conditional logic:
^if($ScreenHeight>100)
<div id="PLOT" height="^value($ScreenHeight)"....>
^else
<div id="PLOT" height="250"....>
^endif
Sure, but unless there is an action code method to read the map-view-based values of $ScreenHeight and $ScreenWidth the above only solves getting poster size this instant as opposed to the longer term, the latter is what underpins my observation. We are still having to set arbitrary values for the non-map-view context and assuming in the latter that we don’t want to see the image at the source (i.e. as in Map view) size.
IOW, I’m trying to resolve a general case not a specific get-it-done-today case. Or, am I missing something here? I’d assumed my suggestions above would not seem egregious. Is there some unseen factor here. e.g. engineering cost, that invalidates the idea? If those factors exist, surfacing them might make it easier to understand the problem in true context. Or, we might formally document that expected use of posters is for map view and export and that is in preview will require non-default settings. Doing the latter might avoid the confusion that set off this discussion.
I’ll also de-interleave this thread on posters in text preview from the original thread.