0

I have created this jsFiddle:

https://jsfiddle.net/j994tnu2/4/

if(textH < (parentH - deviation) || textH > (parentH + deviation)) {
  text.style.transform = "scale(1, " + frameScale + ')';
  //alert("transform");
}

https://jsfiddle.net/j994tnu2/5/

if(textH < (parentH - deviation) || textH > (parentH + deviation)) {
  //text.style.transform = "scale(1, " + frameScale + ')';
  //alert("transform");
}

Version 4 has 1 line uncommented which allows for a tranform: scale() of the div directly containing the text.

Version 5 has this 1 line commented which disallows this to happen.

My concern is that the way I've coded the text to resize is...

textScale1 = 0.78;
textScale2 = 1;
textScale3 = 1.4;
//textScale4 = fontSize2 / fontSize;

//applies the master frameScale once to a single style of a class
fontSize2 = Math.round(10 * fontSize2 * frameScale) / 10;
//uses the relative textScales to this element to style the rest
fontSize = Math.round(10 * fontSize2 / textScale1) / 10;
lineH = fontSize;
margin = Math.round(10 * fontSize2 / textScale2) / 10;
lineH2 = fontSize2;
margin2 = Math.round(10 * fontSize2 / textScale3) / 10;

by manually checking the font-size and margins of every element and changing them to a scale both relative to themselves in the text AND relative to the outer div container size. This is actually the good part which makes the text stay true to itself relative to the original format. However,

The problem I have is the difference between the onload = function and the addEventListener(resize, function). They are coded exactly the same but have "different" results.

If you resize the window you'll see that after about 3 resizes, the text fits the container on an absolute font-size level much more closely and has much less (or none at all) transform: scale() stretching or squashing.

But every time the onload = function gets called, the text will always be way too big or small for the container and will always get stretched or squashed by an unacceptable amount.

How can I code this up to make the font-sizes in the onload = function be true to the starting outer div height?

Thanks for looking into it.

EDIT: It's interesting. Commenting out the onload=function and letting the resize function do the first resize, you will get the exact same result of the onload=function. Which, consistency is good. But why does subsequent resizing increase the accuracy of the font-sizes? Even if I resize up and then back down to near the same spot the text will look less squished and more true to its proportions. The initial resize sucks. Why? How is it possible that it gains in accuracy over time?

ketenks
  • 1
  • 2

1 Answers1

0

So I've kept working at it and saw that the ratio of the outer text div to the inner text div (frameScale in the jsFiddle) would determine the percent deviation at the end. This is what I mean:

However far from 1.0, that frameScale would deviate would determine according to some odd exponential function how far the resultant frameScale was from 1. So if you started from 1 (meaning the outer text div was just as large as the inner text div) then the resultant ratio would also be one. If it was 1.3 then the ratio plummeted to 0.84. If it was 1.6 then it went to 0.72. If it was 2.00 then it went to 0.5 and so on. I couldn't figure it out so I decided to do a workaround.

If resizing it multiple times made the font-sizes more true then I decided to just resize it with the resizeListener function I was already calling. All I needed to do was resize to the grandparent element in the first part of the function and then resize to the parent element in the second part. The one kicker was that the grandparent-to-child height ratio could not be the same as the frameScale (parent-to-child). So I did this:

if(masterScale = frameScale) {
masterScale = masterScale - 0.5;
}

For whatever reason, 0.5 seems to work well. Maybe this will fail in many different situations but for now it's a good workaround. All I did was resize the container twice. Here is the jsFiddle:

https://jsfiddle.net/j994tnu2/6/

EDIT: This doesn't answer the question though. Why is the beginning frameScale's deviation from 1 determine increasing deviations from 1 after the transformation? If I wanted it perfect I could create an if() else if() tower adjusting for this all the way up to some ratio that wouldn't occur naturally:

1.0-1.04 >>> 1.0

1.05-1.29 >>> 0.94

1.3-1.34 >>> 0.84

1.35-1.6 >>> 0.8

1.61-??? >>> 0.7

1.99-??? >>> 0.49

For whatever reason, subtracting the amount needed to make 1.0 for the resultant ratio from the beginning ratio will adjust the resultant ratio to 1; which doesn't make sense. Here is a jsFiddle doing this very thing and with much better results than resizing to the grandparent element:

https://jsfiddle.net/j994tnu2/9/

ketenks
  • 1
  • 2
  • I just wanted to say that I have a working version of this in my book. And it works. It's not perfect but it cures the overflow (not underflow). I can adjust the height of the outer div to shrink it or expand it a little. Which is all most pages need. Beyond that no eReaders support JavaScript or even all of CSS stylings like "position: relative;". So there is no point in something like this until the dumb eReaders can synchronize to some standard and actually allow for modular eBook design. Pretty frustrating. – ketenks Oct 27 '16 at 13:41