My project, Music In the Air, has text on pages like a book where we need Windows line wrapping to match exactly the Mac so that text flow to the next page is identical.
The solution I came up with is to process the text for Windows in advance—add CRs to each visible line of the Mac text field then export the htmlText to the data storage. When that htmlText is set in the Windows field, I also make the field much wider. Now that every visible line ends with a CR, the visible layout of words is the same as Mac. I’m doing this for both English and Chinese characters. (Displaying Chinese characters to properly fill a field of text is a whole ’nother story, but I won’t get into that here.) Peter Bogdanoff ArtsInteractive > On Sep 4, 2022, at 4:49 AM, Pi Digital via use-livecode > <use-livecode@lists.runrev.com> wrote: > > I had a quick turnaround job for some guys in Ghana. It made it a complete > nightmare as I had done the original build in Windows, their main platform, > and they wanted a backup for Mac. As this was for a TV show where the text > was dynamic but had to be identical on both it made it almost impossible. I > had to write multiple conditionals to allow for the two platforms display > differences of baselines and formatting. Now I recommend they only build for > a single platform as it is ‘unreasonable’ to expect that two different > systems will perform or display in the same way. > > Your disturbing highlight of the differences in MacOS appearance was not nice > though. Well worth knowing but not great for us, eh? > > Sean > > >> On 4 Sep 2022, at 10:34, Neville Smythe via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> So I have conducted a more careful test of the proposed method of >> standardising fonts across platforms, that is, installing some Google fonts >> in the standalone for use in labels and fields, with the objective of >> setting the rects of objects on the development platform and having the same >> appearance on all 3 platforms: no more missing pixels or wrapped words >> because of the differences in fonts between the platforms. >> >> Unfortunately the method does quite not give the hoped-for solution. Even >> though the fonts supposedly have the same metrics, the appearance still >> differs between platforms. For both NotoSans and NotoSerif I find the >> baselines differ by one or two pixels between Mac Monterey and Windows >> (which I don’t really understand, since the ascent is built into the font, >> but nevertheless becomes different when rendered). The pixel lengths of the >> tested strings were the same however: allowing just a couple of extra pixels >> height should be sufficient in these cases. However on Linux (Ubuntu), while >> the baselines were the same, the length of rendered strings differed >> markedly, in one test case wrapping a trailing word out of sight. And a >> nasty surprise, the text length on Mac High Sierra was 8% longer than on >> Monterey! >> >> So I’m afraid one must still write once, test everywhere. >> >> Neville >> >> >> >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
