Resizing of text in frontend text fields #539
Comments
|
What kind of content are these items, HtmlText? |
|
Yes. Entries of the RPI public calendar via their iCal feed. |
|
There's a comment from a user also having this problem in the groups at https://groups.google.com/d/msg/concerto-digital-signage/U-mSZZVosxQ/MwMYbpGbYikJ |
ghost
assigned 
|
Anyone find a work around for this one... I've been working my way through the source slowly but I'm not sure even where to start. RSS article descriptions get treated as one big line and then font scales down to incredibly tiny. My iCal feeds look okay though. |
|
@abrigham there's a kind of work around here https://groups.google.com/d/msg/concerto-digital-signage/WIm_qxdgGgk/Jrre-c5IUNQJ |
|
So it looks like the automatic font sizing is done via helpers.js in the Autofit function. Font size starts at 100px and goes down by 1 until the content is deemed to fit within the position's allocated "box". I wonder if there is some way to tell the content that the text can wrap in the position (css style maybe) and if it would remedy the problem. I'd also think that going down by 2 instead of 1 or attacking it in a binary sort type method might be more efficient? |
|
This same behavior is exhibited when setting up a ticker text. Short text snippets scale to an appropriate size, but if you enter a big paragraph of text without linebreaks (something that should probably not even be allowed by default as the ticker would work best for short snippets) it all goes on one loong line, which becomes microscopic. It doesn't use more than a fraction of the available height. Manually adding the line breaks allows one to manipulate how it gets split, but text in these fields and the RSS/text field should ideally just use up all the space and show at the appropriate font size. Short text, long text with artificial word line breaks when adding the ticker and long text with no artificial line breaks. Only the short text looks ok. (You probably knew all this but hey, screenshots are fun.) The entire display is 1920 wide (full HD.)
|
|
See PR #772 |
* refs/heads/master: Flux it, we're doing it live... refactor logic into model Trying to see if not doing a test involving Rack::Test::UploadedFile will help 1.8.7 pass update new location for closure compiler source fix #539 text autosizing Clean up an i18n deprecation warning add back mysql dependency Downgrade RubyZip to support ruby 1.8 use capitalized file name Alter test to use package add the mysql dependency back clean up template#import create media from image zip entry make translation key singular for consistency add missing translation add ruby zip and start reading uncompressed data Conflicts: Gemfile Gemfile.lock
* refs/heads/master: Flux it, we're doing it live... refactor logic into model Trying to see if not doing a test involving Rack::Test::UploadedFile will help 1.8.7 pass update new location for closure compiler source fix #539 text autosizing add back mysql dependency Downgrade RubyZip to support ruby 1.8 use capitalized file name Alter test to use package add the mysql dependency back clean up template#import create media from image zip entry add ruby zip and start reading uncompressed data
|
I don't think this considers the padding that may be specified in the style for the position... need to make sure that the style is applied to the hidden element before sizing is determined. |
|
@bamnet do you have any ideas on this? There are still certain instances where the autosizing isn't quite accurate, but instead of being too small, a little bit is clipped off the bottom. Looking into this I've found that the div is actually sized longer than the field height. I had to play around with the window to check various sizing situations. I also placed a border style in the position's style column in the template setup-- that's when I noticed that the bottom of the border wasn't showing up. It's super weird because console.logging the size of temp_dom it always was less than the field's height. So because I knew that the autosizing technique appends the element to document.body instead of the element it is actually going to appear in, I thought that maybe the styles of the position were not being factored in to the sizing since they were not applied to the hidden element. [I have my text field position styled with padding: 1em.] So I then added some code to grab the position's style and apply it to the hidden element (temp_dom) before calling the autosize function. This made it go to 1px font size every single time. Seems that if the temp_dom has any padding set, it goes to 1px font size. Anyway, after spending 4x way too much time on this, I undid all my changes and figured I'd get the master's assistance (that's you btw). |
|
I've tried a few more variations, including having it render the elements in the dom (but hidden in other ways) to get the layout and rendering to occur as it would when it is actually injected, but still no go. There's something weird about it-- it can be sized to fit, but when it's actually injected it doesn't always fit anymore. The only reliable way to size it to fit accurately was to size it after it was injected. |
Can someone tell me briefly about how i could override the sizing in the front end for items that have text that should wrap? I'm working with some items that have long sentences and they become unreadable in the side area due to font size shrinkage.
The text was updated successfully, but these errors were encountered: