CCS/TM4C1290NCPDT: Bigger Font more than 100 pt !!

smit majithia said:

Hey i want to have bigger fonts more than 100 pt !!

Do note - 'Hey' is far from a respectful salutation - it proves far too forceful - almost commanding.      Thus not the ideal means of encouraging others to ASSIST you!    (in our case - you/I 'meet again.')

To your issue - have you checked how MS Windows (in general) creates & manages their 'scalable fonts.'     Examining the 'successful' methods of skilled others - often saves hours (days in this case) of your time & effort.    There IS a caution though - (many/most WIN Fonts are copyright protected - you must proceed w/care.)     There do exist 'free fonts' - usually these are not as visually compelling - yet deserve your search.

Should you find an acceptable font - check to insure that it may be scaled to 30 'points'  (which may translate to 30 'pixels' - should your objective be some 'Flat-Screen Display.'     (BTW - the display vehicle for your GIANT FONT - is silent!)

Assuming that you can find an adequate font - and it natively may extend to 30 points (or beyond) you should be able to "Magnify it' by a factor of four.     Each pixel of the base font would be processed to produce a 16 pixel total (4x4 pixel cluster.)      In this manner a 30 pixel font would expand to (30x4 = 120 pixel height.)     There IS a downside - each of your new font's individual characters would have a 'squared-off' (i.e. 'jagged edge')     In the past - for far smaller fonts - firm/I would engage the local 'gifted high school' - to manually 'clean up' our 30-40 (maximum) height fonts.    

A far better method would be to employ a powerful computer (ideally a PC) to 'smooth & remove' - any/all - rough edges of your new font.    It is those 'PC Processed Characters' then - which would make up your Giant Font.    (I believe the ARM M4 is 'Not up to' such a task - would spectacularly SLOW your Screen Writes.    A 220MHz Cortex M7 (may) work - yet such achievement is unknown - at this time.)

One of the 'horrors' of this vendor's Graphic Library - is their 'placement of all Font Data w/in the MCU's internal memory space!'      No (real) Graphic Designer would have done so - as that causes:

• each/every program load to require much more time
• while 'eating memory' - based entirely upon the Size & Number of Such Fonts
• further - Graphic Images - also are stored (only) w/in the MCU's memory - causing (even) added delay & loss of resource

Past (real) Graphic Designers would insure that such Font & Graphic Image Data - was stored in Fast Access, yet EXTERNAL MEMORY - which avoids the 2 'killer defects'  identified above.   (killer in my opinion).    To 'head-off' the opposing, "External Memory would ADD Cost" - that external memory may be, 'Employed ONLY during Development - during the (easily) HUNDREDS of Program Loads" yielding (surely) HOURS - but more likely DAYS - of Saved Time!      And how COST-SAVING THAT!    (due to vastly faster Program Loads!)      Once the code is deemed 'approved/acceptable' - then it may be placed ENTIRELY w/in the MCU's memory store - saving the cost of the external memory - yet  STILL ENABLING - a VASTLY MORE EFFICIENT DEVELOPMENT VEHICLE!

Our poster here is SO VAGUE in his requirement - that (OTHER) Advantaged Methods - which (may) work - can not properly be considered.     

Removing that 'Hey' - while providing meaningful detail (I'll leave that determination to you) potentially enables (other) resourceful approaches - to be considered & (perhaps) presented...

One hopes that past (claimed to be needed) - will ... someway ... somehow  'FIT w/in MCU's Flash store.'     (while leaving adequate room - for User's code - and not looking too awkward (due to the jagged font edges - in that process!)  

I've just read Amit's past post - it makes no note of the (potentially) enormous size - which such Giant Font - most always - demands/extracts!     In the development of such a program - many, many program downloads is,  "Par for the course."     And each one will take NOTABLY LONGER - due to that HUGE Graphic FONT - being repetitively sent - time & again!    That's NOT GOOD!

May it be noted too - that 'SO MANY Here' - report on-going 'JTAG Issues.'     As each/every download grows SO EXPLOSIVELY - do we not  (GRAVELY) - invite the dreaded 'JTAG LOCK-OUT?    And as witnessed here - many times - recovery is NO SURE THING!     What then?

Burdening the MCU's internal memory - and download mechanism - multiple times - with such EXTREME storage needs - proves NOT - the 'normal/customary' means of  'LONG DEEMED EFFECTIVE - Font & Image EXTERNAL storage!'     NOT INTERNAL!    (as the earlier post greatly detailed...)

As the font's pixel inventory increases - while the screen stays reasonably (size) consistent - then Yes - higher DPI does lead to a 'larger than usual'  font requirement.   (to yield the targeted 'viewable font spec.)

You (may) be able to 'help yourself.'      'Ftrasterizer.c'  appears - in all of its 'naked' Source Code glory - awaiting your 'skillful' examination.    

As my report clearly revealed - the code 'cuts off @ 100 points' - yet that's NOT explained nor detailed.     Maybe - you can extend that upper limit - enabling you to produce a more visually notable font.

That said - my report (also) detected that as the font 'Enlarges' - it  'may pierce the 256 byte limit'  (Who knew?   Again that's w/in my report).    

Your review of the source file should enable you to determine - 'How or (even) If' - (both) the '100 point limit'  AND  the '256 byte limit' (may) - be overcome...

smit majithia said:

can it be escalte to the maker of Ftrasterizer.c

That's up to this vendor - (I have (only) profitable, 'User-Specifier' relationship w/this vendor.)    [don't know if you had that awareness]

You must consider - in ALL of my time here (now > 10 years) [prior to being 'chased away' - by heavy handed 'LIKE-less e2e crüe.]    I've NOT encountered - such a 'Giant' (not just bigger - to be fair) Font request.

As you grow/mature - you will learn that 'LARGE SALES' - and those 'design elements' - which (surely) yield such' - receive  EXTREME Vendor focus.     (as they should - both here - and at (other) semi-vendors!)

In that 'inside light' - how do 'you' rate  the chance for such an,  FTRasterizer 'escalation?'

And - is not your issue - 'predominantly brought about' - by your (perhaps unwise) choice of a, 'Too Pixel Rich' Display?      (some 'slight' note of 'thanks' - somehow has been missed ... yet remains awaited - and  warranted.)

May I note - my 'very special Decoder Ring' ... resolves vendor's, '(not) at this time' ... to 'never!'      ('LIKE's return - enjoys - better odds...)