Bugzilla – Bug 7374
_DBL strings for large font no longer supported
Last modified: 2009-09-08 09:22:38 UTC
At some point the support for *_DBL strings, used in large/huge/double size font, has been removed. Don't know whether this was deliberate, but we'll either have to put it back in (if this is still a supported feature) or can remove the remaining *_DBL strings. I'd guess that feature is gone. There are only about 15 strings using it at all. Probably not worth adding the overhead for those few cases to the display code.
Doesn't $client->doubleString use the double strings correctly? Can you give me an example of one which is not working - this should not have been removed!
*** Bug 7375 has been marked as a duplicate of this bug. ***
> Doesn't $client->doubleString use the double strings correctly? Ah, that code moved to a new place? I only looked at Strings.pm, sorry. But it seems to have chaned behaviour. > Can you give me an example of one which is not working - this should not have > been removed! I've tested using the following custom-strings.txt file: SHUFFLE_ON_SONGS_DBL DE Titelreihenfolge SHUFFLE_ON_ALBUMS_DBL DE Albumreihenfolge SHUFFLE_OFF_DBL DE Zufall aus ...to have shorter versions of those strings when pressing the shuffle button. Maybe showBriefly() has changed?
Did that ever work??? At present the display code doesn't do anything to select the normal or double strings, its the caller's responsibility to call $client->doubleString to do this. If you grep for doubleString, you will see that in other places the caller tests for linesPerScreen first and then calls doubleString if it wants the shorter string.
> Did that ever work??? Yes - otherwise I would not have noticed. But I didn't find a change breaking it neither. > At present the display code doesn't do anything to select the normal or double > strings, its the caller's responsibility to call $client->doubleString to do > this. Display::showBriefly() (which I assume is used) does simply shift down the first line to the second (as the latter is actually displayed).
So, is this actually broken?
Recording some details that I responded by email about: Its too late to do anything in the Display codeas the string token has already been converted to a string. This needs to be done at the time that $client->string is called, i.e. before sending anything to the display code. So in my view if something wants to use the DBL strings then it needs to changed to use $client->doubleString when it converts a string token to a real string - this is before handing off to the display code. So we just need to update the places where these string tokes are referenced to check for linesPerScreen and use doubleString if appropriate.
I'm not sure this issue is worth investigating. I reported it because some guy in the German forums was using a custom-strings.txt file to get shorter versions in his preferred full size font. As we're barely using _DBL strings ourselves (less than 20 strings, some of them not even available in EN) I'd rather vote for officially bury that feature to free some bytes.
Agreed - Its probably most noticable for large text on a text screen anyway, so probably not worth doing too much more work on.
(In reply to comment #8) > I'm not sure this issue is worth investigating. I reported it because some guy > in the German forums was using a custom-strings.txt file to get shorter > versions in his preferred full size font. As we're barely using _DBL strings > ourselves (less than 20 strings, some of them not even available in EN) I'd > rather vote for officially bury that feature to free some bytes. > Marking bug as invalid for now, if this issue comes up later please reopen the bug.
Reduce number of active targets for SC