Allow Embedding GeoGebra from GeoGebraTube in HTML

[Jahrme]

Currently the author is required to provide the @geogebratube attribute and it is highly suggested to provide both @height and @width (using the defaults provided by GeoGebraTube) as the sizing is highly variable (both in size and aspect-ratio) between projects. The author is also able to set any of the settings provided to the author in the embed window on GeoGebraTube and if unset we use the defaults.

[Alex-Jordan]

Let's consider giving these no border, and letting PTX's CSS for the iframe do any bordering (or maybe none at all).

I welcome other people's input, but I would always want the pan-and-zoom off, so maybe that would be the default. The reason is that in scrolling through a long page, if the geogebra iframe suddenly finds itself beneath your mouse and you are still trying to scroll, the zoom takes over. You stop scrolling, and instead end up zoomed in to the max on the geogebra.

[Jahrme]

Update removes the if referred to by Alex. Instead the xsl:whens are predicated upon both the existence of @toolbar and @toolbar-help = 'yes|no'.

As for the border, the color is part of the source url, and that is all that is being set. I agree that styling should be handled by PTX's CSS, so maybe we should agree on a neutral color to send as part of the url, have it be set by the XSL, and then let the styling work from there.

[rbeezer]

Thanks, Jahrme. Some suggestions:

Widths should be percentages, and heights should come from an @aspect-ratio. See #536 for direction (and maybe a precursor PR to do just that).

The sample article then needs at least one example, plus all those attributes need to be semi-documented there, and rolled into the DTD.

[Jahrme]

Okay, what form should @aspect-ratio take? If we are basing it off of video it would make sense to denote it using a colon, e.g. @aspect-ratio="16:9", and for a GeoGebra embedding it could take the corresponding form of @aspect-ratio="425:373" where the two numbers are the default width:hight of the GeoGebra applet.

The issue here is that the url used to retrieve the applet must have a width and height specified separate from any sort of styling width/height.

[rbeezer]

Can you write a modal template like the image-width one that allows @aspect ratio to be a ratio (check for colon) or a real numer (decimal)?

Then use percentages and widths to convert to pixels (which I assume the GGB applet wants) for the URL.

On May 29, 2017 9:36:14 PM PDT, Jahrme Risner notifications@github.com wrote:

Okay, what form should @aspect-ratio take? If we are basing it off of video it would make sense to denote it using a colon, e.g. @aspect-ratio="16:9", and for a GeoGebra embedding it could take the corresponding form of @aspect-ratio="425:373" where the two numbers are the default width:hight of the GeoGebra applet.

The issue here is that the url used to retrieve the applet must have a width and height specified separate from any sort of styling width/height.

[rbeezer]

More, better, details.

Write a modal template that provides pixel count as result. Call it image-height. Check existence, or provide defaults for @width in percent, @aspect in colon form or as real number.

Likely just use existing image-width template to cover the width part of this.

You could do this on a new PR and then employ here.

[Alex-Jordan]

I am watching the XSL for the embed URL closely, because I need to repeat it in mathbook-webwork-pg.xsl and use the same url but in a different way. (Which makes me wonder if the url construction should somehow go in common...)

Can I suggest a small change re stb and stbh? In all cases, the url needs a true or a false for each of these. When manually choosing options on GeoGebra's site, it won't let you set stbh unless stb is true. And if stb is false, stbh is forced to be false.

I think the logical equivalent of that would be:

    <xsl:text>/stb/</xsl:text>
    <xsl:choose>
        <xsl:when test="@toolbar = 'yes'">
            <xsl:text>true</xsl:text>
        </xsl:when>
        <xsl:when test="@toolbar = 'no'">
            <xsl:text>false</xsl:text>
        </xsl:when>
        <xsl:otherwise>
            <xsl:text>false</xsl:text>
        </xsl:otherwise>
    </xsl:choose>
    <xsl:text>/stbh/</xsl:text>
    <xsl:choose>
        <xsl:when test="@toolbar = 'yes' and @toolbar-help = 'yes'">  <!-- change made here -->
            <xsl:text>true</xsl:text>
        </xsl:when>
        <xsl:when test="@toolbar-help = 'no'">                        <!-- change made here -->
            <xsl:text>false</xsl:text>
        </xsl:when>
        <xsl:otherwise>
            <xsl:text>false</xsl:text>
        </xsl:otherwise>
    </xsl:choose>

As it is now, stbh can end up true when stb is set to false. Probably harmless, but the manual settings page on GeoGebra is built to make this situation impossible. (Maybe PTX should spit out a warning if @toolbar = 'no' and @toolbar-help = 'yes'.)

[Alex-Jordan]

Apparently, "GeoGebraTube" is a name no longer in use, and now it is "GeoGebra Materials": https://en.wikipedia.org/wiki/GeoGebra#GeoGebra_Materials_Platform

Before we dig in too deep with this and #586, maybe @geogebratube needs to be @materials-id or something like that.

[Alex-Jordan]

Hi Jahrme,

On #586 I'm going to proceed with changing "geogebretube" to "materials-id" and proceed with the things that are going on in that branch. Specifically, the thumbnail collection and the use of GeoGebra in mathbook-webwork-pg.xsl. Is that OK with you? Stop me soon if you think "materials-id" may be a bad name.

Alex

[rbeezer]

I'd like to avoid hyphens in attributes, except in rare cases. Can we use just @materials?

On 05/31/2017 05:37 PM, Alex Jordan wrote:

Hi Jahrme,

On #586 https://github.com/rbeezer/mathbook/pull/586 I'm going to proceed with changing "geogebretube" to "materials-id" and proceed with the things that are going on in that branch. Specifically, the thumbnail collection and the use of GeoGebra in mathbook-webwork-pg.xsl. Is that OK with you? Stop me soon if you think "materials-id" may be a bad name.

Alex

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/587#issuecomment-305356570, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2cqFFCMzEBSEOrTFnHwsvdOQhO8dKks5r_gfkgaJpZM4NnKmb.

[Alex-Jordan]

Va bene :)

Why are you still here?

[Alex-Jordan]

Widths should be percentages, and heights should come from an @aspect-ratio.

I get that this is PTX standard, but I will point out some awkwardness this will cause. An author finds something on GGM that they like. They look at its embed code, which will say something like width should be 425, height should be 373. These numbers have been chosen by the GGM author as good for the specific content inside. So to duplicate that, the PTX author will have to calculate something like width=70.83%. (My point is that with authors setting percents for widths, it would be ideal [to me] if that meant they were setting the percent width they want the thing to occupy. But here it is a percent width imposed on them from GGM.)

Related: we allow non-percent widths on the images that WeBWorK produces internally, which are also pixel counts.

Would the author specify something like aspect-ratio = "373:425"?

Last comment: nothing the PTX author sets is used for the width/height of the scraped thumbnail. That thumbnail will have the pixel width/height that GGM is suggesting, no matter what the PTX says. Then, when that thumbnail is used in the print copy, do we honor the width that the PTX author set? That GGM was suggesting? Make thumbnails a fixed width in print regardless of the PTX width and the GGM width?

[rbeezer]

Does the ggb site report the authors ideal pixel counts in a way we can scrape them with the mbx script?

If an author needs to manually inspect the embed code then another step to divide the two dimensions does not concern me.

Presumably the thumbnail images may be inspected for their dimensions and so @aspect may be computed, though it is not clear to me how to communicate that back into the latex output.

This does not address all your comments but I am not in a position now to make a comprehensive reply.

I thought you were designing the scheme that will make all of this easy? ;-) ;-)

On June 3, 2017 2:35:21 AM GMT+02:00, Alex Jordan notifications@github.com wrote:

Widths should be percentages, and heights should come from an @aspect-ratio.

I get that this is PTX standard, but I will point out some awkwardness this will cause. An author finds something on GGM that they like. They look at its embed code, which will say something like width should be 425, height should be 373. These numbers have been chosen by the GGM author as good for the specific content inside. So to duplicate that, the PTX author will have to calculate something like width=70.83%. (My point is that with authors setting percents for widths, it would be ideal [to me] if that meant they were setting the percent width they want the thing to occupy. But here it is a percent width imposed on them from GGM.)

Related: we allow non-percent widths on the images that WeBWorK produces internally, which are also pixel counts.

Would the author specify something like aspect-ratio = "373:425"?

Last comment: nothing the PTX author sets is used for the width/height of the scraped thumbnail. That thumbnail will have the pixel width/height that GGM is suggesting, no matter what the PTX says. Then, when that thumbnail is used in the print copy, do we honor the width that the PTX author set? That GGM was suggesting? Make thumbnails a fixed width in print regardless of the PTX width and the GGM width?

[rbeezer]

A follow-up on one part of this. A thumbnail image has the desired aspect-ratio. So scaling the width only will preserve the aspect-ratio.

[rbeezer]

If I wrote a general aspect ratio handling template, then I might be able to amend this so it is ready to go. Would there be any objections?

[Alex-Jordan]

Is it still your plan to have the PTX author specify a percent width and an aspect-ratio? Sorry if I'm being dense, but say the natural dimensions that GM specifies are 314px of width and 208px of height. What is the PTX author supposed to do?

If I understand right, they are supposed to calculate 314/600*100 for a width percentage. Is it reasonable that they round to 52%? Then 52% of 600 is 312 pixels, and when a 314px rasterized image is rendered at 312 pixels, a one-pixel vertical line somewhere can completely disappear. Or a more common issue would be that the image just looks off in some mildly discernible way.

Maybe authors are not supposed round?

Does the ggb site report the authors ideal pixel counts in a way we can scrape them with the mbx script?

I never looked into that. Is it worth pursuing? Then we are talking about having to run the mbx script to get these sized right in HTML (as opposed to just getting the thumbnails for PDF).

I thought you were designing the scheme that will make all of this easy? ;-) ;-)

Right :) Well, I personally believe I have latex-image-code solved now. Just need to report to the gorup, and need you to toss out your sidebyside panel construct in print which interferes with my solution :) But no perfect solution yet outside of latex-image-code.

[rbeezer]

On 07/03/2017 04:47 PM, Alex Jordan wrote:

Is it still your plan to have the PTX author specify a percent width and an aspect-ratio? Sorry if I'm being dense, but say the natural dimensions that GM specifies are 314px of width and 208px of height. What is the PTX author supposed to do?

If I understand right, they are supposed to calculate 314/600*100 for a width percentage.

Yes.

Is it reasonable that they round to 52%?

Yes.

Then 52% of 600 is 312 pixels, and when a 314px rasterized image

I was fine until I got here. I'm talking about GeoGebra interactive applets, or whatever they are called. Do they come as rasterized images? Perhaps I'm being dense.

I thought you were designing the scheme that will make all of this easy? ;-) ;-)

Right :) Well, I personally believe I have |latex-image-code| solved now. Just need to report to the gorup, and need you to toss out your sidebyside panel construct in print which interferes with my solution :) But no perfect solution yet outside of |latex-image-code|.

Yes, the side-by-side panel construct is a bit odd, but after today's work (not public), I can't see abandoning it. In other words, a solution should recognize that people want horizontal layout. I have no problem in XSLT with grabbing the enclosing @width, but I don't expect that is the difficulty.

[Alex-Jordan]

I was fine until I got here. I'm talking about GeoGebra interactive applets, or whatever they are called. Do they come as rasterized images? Perhaps I'm being dense.

This PR will set the attributes for a geogebra. So even though right here it's put to use as the width of the interactive embedded HTML thing, it's an attribute that will apply to the static png elsewhere. I don't think we have to worry about the 312/314 pixel issue in print, but on some screens with some resolutions it could be ugly. I'm thinking ePub on a phone and a few other things.

Also I'm hoping nothing makes it into the HTML as a percentage, but rather as a pixel count calculated from 600. Because small screens have been on my mind since Nick brought an issue to me with a graph that was unreadable on a phone, but would be readable if the percentage could be ignored, or if the rendered image were loaded in the HTML using an absolute size, not a relative size.

It still seems wrong for authors to calculate a percentage to write into their source that is all based on the 600 pixel HTML width. It seems like this clashes with the idea of future-proofing your source.

[rbeezer]

Right, then placement of the static PNG just respects/interprets/uses the width percentage and the height comes along for free based on the inherent aspect-ratio of the image itself.

In other words "it's an attribute that will apply to the static png elsewhere" might be re-phrased as "it's an attribute that is available elsewhere".

Nothing is suppose to make it into HTML as a percentage, it should be absolute based on the 600 pixel. Do you see otherwise somewhere?

Authors should not be writing in percentages based on any assumptions. They should be indicating how much room they think the things should occupy. If a GGB author has made assumptions, then shame on them. ;-)

On 07/05/2017 06:36 PM, Alex Jordan wrote:

    I was fine until I got here. I'm talking about GeoGebra interactive
    applets, or whatever they are called. Do they come as rasterized images?
    Perhaps I'm being dense.

This PR will set the attributes for a |geogebra|. So even though right here it's put to use as the width of the interactive embedded HTML thing, it's an attribute that will apply to the static png elsewhere. I don't think we have to worry about the 312/314 pixel issue in /print/, but on some screens with some resolutions it could be ugly. I'm thinking ePub on a phone and a few other things.

Also I'm hoping nothing makes it into the HTML as a percentage, but rather as a pixel count calculated from 600. Because small screens have been on my mind since Nick brought an issue to me with a graph that was unreadable on a phone, but would be readable if the percentage could be ignored, or if the rendered image were loaded in the HTML using an absolute size, not a relative size.

It still seems wrong for authors to calculate a percentage to write into their source that is all based on the 600 pixel HTML width. It seems like this clashes with the idea of future-proofing your source.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rbeezer/mathbook/pull/587#issuecomment-313271428, or mute the thread https://github.com/notifications/unsubscribe-auth/ABy2co8GW-vkABW60S7B8lHQSqsL1zSEks5sLDo7gaJpZM4NnKmb.

[Alex-Jordan]

Yes, the side-by-side panel construct is a bit odd, but after today's work (not public), I can't see abandoning it. In other words, a solution should recognize that people want horizontal layout. I have no problem in XSLT with grabbing the enclosing @width, but I don't expect that is the difficulty.

Off topic for this thread, but here is what I mean. Horizontal layout is good and should be supported. But the method of creating the image off to the side and then stretching/compressing it to fit the sbs panel is the problem. I'm sure you had good reason to move to that from the older method of building the panel content "inside" the panel, but still it's the one thing between latex-image-code and what I think is a universal solution/philosophy to such images no matter what flavor of tikz/pgfplots/xypic/pstricks/... is being used.

[Alex-Jordan]

Nothing is suppose to make it into HTML as a percentage, it should be absolute based on the 600 pixel. Do you see otherwise somewhere?

I don't , but if I understand right you had yet to modify this PR to make the author-defined widths be percentages instead of pixels.

They should be indicating how much room they think the things should occupy.

But they can't, if using a percentage. Then can specifically for a 600-pixel HTML page. But then they can end up with unreadable content on say, a phone. Example: an image looks perfect at 30% on the regular full-size HTML. And then on the phone the containing article is still set to 30%, so it's details are unreadably small. This is an issue with some of the MT Hood images. And probably elsewhere, but we haven't been monitoring small screen content well.

[Alex-Jordan]

Nothing is suppose to make it into HTML as a percentage, it should be absolute based on the 600 pixel. Do you see otherwise somewhere?

This has me thinking, did you mean nothing at all? Even outside the context of a geogebra? Because the enclosing containers of general images are using percents. Like the object elements around the images here: http://mathbook.pugetsound.edu/examples/sample-article/html/graphics.html

[rbeezer]

I have GeoGebra materials implemented in a basic way. I'm going to close this - open a new issue of something needs work.