Allow Embedding GeoGebra from GeoGebraTube in HTML #587
Conversation
|
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. |
xsl/mathbook-html.xsl
Outdated
| </xsl:otherwise> | ||
| </xsl:choose> | ||
| <xsl:text>/stbh/</xsl:text> | ||
| <xsl:if test="@toolbar"> |
There was a problem hiding this comment.
I think that this if should not be here. Like the previous attributes, it should dive into the choose.
|
Update removes the 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. |
|
Thanks, Jahrme. Some suggestions: Widths should be percentages, and heights should come from an The sample article then needs at least one example, plus all those attributes need to be semi-documented there, and rolled into the DTD. |
|
Okay, what form should 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. |
|
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 ***@***.***> wrote:
Okay, what form should ***@***.***` take? If we are basing it off of
video it would make sense to denote it using a colon, e.g.
***@***.***="16:9"`, and for a GeoGebra embedding it could take the
corresponding form of ***@***.***="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.
|
|
More, better, details. Write a modal template that provides pixel count as result. Call it Likely just use existing You could do this on a new PR and then employ here. |
|
I am watching the XSL for the embed URL closely, because I need to repeat it in Can I suggest a small change re I think the logical equivalent of that would be: As it is now, |
|
Apparently, "GeoGebraTube" is a name no longer in use, and now it is "GeoGebra Materials": Before we dig in too deep with this and #586, maybe |
|
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 |
|
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 <#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
<#587 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABy2cqFFCMzEBSEOrTFnHwsvdOQhO8dKks5r_gfkgaJpZM4NnKmb>.
|
|
Va bene :) Why are you still here? |
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 Related: we allow non-percent widths on the images that WeBWorK produces internally, which are also pixel counts. Would the author specify something like 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? |
|
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 ***@***.***> 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?
|
|
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. |
|
If I wrote a general |
| <xsl:text>false</xsl:text> | ||
| </xsl:when> | ||
| <xsl:otherwise> | ||
| <xsl:text>true</xsl:text> |
There was a problem hiding this comment.
My suggestion is still to make this false as the default.
|
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?
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).
Right :) Well, I personally believe I have |
|
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.
|
This PR will set the attributes for a 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. |
|
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
<#587 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABy2co8GW-vkABW60S7B8lHQSqsL1zSEks5sLDo7gaJpZM4NnKmb>.
|
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 |
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.
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. |
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 |
|
I have GeoGebra materials implemented in a basic way. I'm going to close this - open a new issue of something needs work. |
Currently the author is required to provide the
@geogebratubeattribute and it is highly suggested to provide both@heightand@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.