1

I really hope, you are able to assist me on this one, as I'm tearing my hair out... I have a little marquee, based on this code: http://jsfiddle.net/TCJT4/525 that feeds some text.

Here's how it looks on an iPad 6... and please disregard from the preliminary design, but this is how it should look: enter image description here

Here's how it looks on an iPhone 4S:

enter image description here

The ticker is retrieved from the exact same source, but as you can see, the text appears larger on the iPhone (the iPad image is zoomed, so it appears larger, but in reality, they are both displaying a 320x30 pixels placeholder. The text is temporarily hardcoded to 20px in height and I've tried using other units as well... the banner still looks different on the devices.

I did some debugging of the ticker container/placeholder, as well as the detected banner height and disabled all text-adjusting elements. Here's a result of some of the properties:

iPad 6:   Tickerplaceholder DIV-height: 24pixels, bannerheight: 30px, pixelaspect-ratio: 2
iPhone:   Tickerplaceholder DIV-height: 32pixels, bannerheight: 30px, pixelaspect-ratio: 2
PC (Chrome): Tickerplaceholder DIV-height: 24pixels, bannerheight: 30px, pixelaspect-ratio: 1;

I find it very strange that two retinadisplay devices display the same banner differently - and that the iPad and the PC displays them correctly.

The ticker can also be found here in its latest form: www.videobanner.dk/ph.html

Anders
  • 251
  • 3
  • 13

2 Answers2

0

Pixels are different physical sizes on different devices - so 24px is smaller on one device than on another.

For text, if you use points instead then the size will be the same across devices - they will all make 72pt 1 inch (thereabouts).

Of course this means you have to use text and not bitmaps etc.

Mobile devices may also have a zoom level set for readability (by the user) which will also affect the size - eg you specify 24pt or px and the browser makes it 36pt or px - the calculated size in the inspector will be different to the styled size - to get around this you need to set a value somewhere, then see what it actually is when rendered and apply a ratio to get what you want (via javascript). I've used code like this in the past to ensure text fitted in a box of a given pixel size;

var fontScale = 1 ;
var mySpecifiedFontSize = 24 ; 
var myTextElement = document.getElementById("MY_TEXT_ELEMENT_ID") ;
function fontScalingCorrection(){
    var style = window.getComputedStyle(myTextElement);
    var fontSize = parseInt(style["font-size"]);
    if(!isNaN(fontSize)){
        if(fontSize !== mySpecifiedFontSize){
            fontScale =  (mySpecifiedFontSize / fontSize) * fontScale  ; //allows for multiple calls
            myTextElement.style.fontSize = (fontScale * mySpecifiedFontSize) + "px" ; //or units used
        }
    }
}
//after the element has been drawn once ( or use another element as a size marker )
fontScalingCorrection();
Bob
  • 1,589
  • 17
  • 25
  • Seems retina displays do have different pixel densities so it may be the issue - https://en.wikipedia.org/wiki/Retina_Display#Models – Bob Jan 17 '17 at 18:27
  • Actually I have seen text set with js at 24px sized at 36px on a phone because of user settings - was trying to size text to a box - used the ratio thing to fix it. – Bob Jan 17 '17 at 18:33
  • Hello Bob. Thank you for taking your time, helping me out. I tried your code, but it didn't make much difference, as the iOS browser behaved unpredictably, changing size over time, even with almost all javascript deactivated - something, I should have mentioned, sorry :-( The problem was an error in iOS Safari, occurring only when handling unordered lists, containing text that was "too long", which simply returned incorrect heights. I was able to bypass the problem by splitting the string into groups of 5 and concatenate it afterwards - not pretty, but now it works. – Anders Jan 19 '17 at 15:51
  • Good to know. Best post that as the answer and accept it before someone else gets it in :) – Bob Jan 19 '17 at 16:24
0

The cause of the problem is related to a quirk or error in iOS Safari, which returned an incorrect and unpredictable height when dealing with unordered lists, containing text of various lengths. This became apparent when I compared different text lenghts on different platforms. No fix has been found, but I was able to circumvent the problem by splitting one string into several shorter strings, such as 

<li>This is a text that </li><li>doesn't go well with iOS</li>

In my project, this solution also works... perhaps not that pretty, though.

Anders
  • 251
  • 3
  • 13