| Summary: | PATCH: addition of optional DPI-scaling of fonts | ||
|---|---|---|---|
| Product: | SDL_ttf | Reporter: | David Ludwig <dll> |
| Component: | misc | Assignee: | Sam Lantinga <slouken> |
| Status: | RESOLVED FIXED | QA Contact: | Sam Lantinga <slouken> |
| Severity: | normal | ||
| Priority: | P2 | CC: | dll, glex.spb, sezeroz, sylvain.becker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
SDL_ttf DPI-scaling patch
(same thing from glebm@ for reference) updated DPI-scaling patch for default/2.0 branch updated DPI-scaling patch for SDL-1.2 branch |
||
If this patch looks good, and you'd like me to push it to hg.libsdl.org, let me know, and I'll be happy to do so. If you have any concerns, comments, or questions, please let me know as well! Cheers! -- David L. I've made an almost identical patch today and then discovered this! Can someone please merge this? Thanks! Background: Many retro-gaming devices, such as RG300, LDK, etc, use non-square pixels (320x480 with wide 2:1 pixels). These devices run Linux and most apps on them use SDL1.2 (but generally just upscale from 320x240). With this change, it will be possible to improve font rendering in many of these apps. (attaching my patch for reference, it's basically identical except for a tiny function naming difference) Created attachment 4141 [details]
(same thing from glebm@ for reference)
Created attachment 4142 [details]
updated DPI-scaling patch for default/2.0 branch
dludwig: Here is an updated version of your patch to default/2.0 branch:
- Updated so that it applies to current hg and builds: Required adding
another DPI function, i.e. TTF_SetFontSizeDPI().
- Minor tidy-ups to comments and the commit message.
Please confirm the changes are OK.
Sylvain, Sam: Is this OK to apply?
Created attachment 4143 [details]
updated DPI-scaling patch for SDL-1.2 branch
glebm: Here is an updated version of your patch to SDL-1.2 branch:
- Fixes TTF_OpenFontRWDPI() to use dpi params instead of 0.
- Changes ??RWDPI function names to ??DPIRW for consistency. (RW
is a suffix to an existing function name.)
- Changes the horz_resolution and vert_resolution parameter names
to short hdpi and vdpi as dludwig's version.
- Adds the small DPI documentation before FT_Set_Char_Size() like
in dludwig's version.
Please confirm the changes are OK.
I'd be willing to apply this to SDL-1.2 branch, only if dludwig's
patch to default/2.0 branch is OK'ed.
Thank you Ozkan, the changes look good! Hi, the patch looks good ! I'm not really a user of DPI functions but it seems convenient, especially if one want a stretching by setting a different vertical/horizontal DPI ! (In reply to Sylvain from comment #7) > Hi, the patch looks good ! I'm not really a user of DPI functions but it > seems convenient, especially if one want a stretching by setting a different > vertical/horizontal DPI ! OK then, patches are applied. SDL-1.2 branch: http://hg.libsdl.org/SDL_ttf/rev/7dbd7cd826d6 default branch: http://hg.libsdl.org/SDL_ttf/rev/d56d67db41d8 Closing as fixed. |
Created attachment 2128 [details] SDL_ttf DPI-scaling patch This patch allows TTF_Fonts to be created with DPI resolutions other than FreeType's default (of 72 DPI). Doing so allows fonts to be scaled linearly (at runtime), whereas point-sizes often do not scale linearly. Four new functions are added to SDL_ttf to facilitate this change: SDL_OpenFontDPI SDL_OpenFontIndexDPI SDL_OpenFontDPIRW SDL_OpenFontIndexDPIRW Each DPI-enabled SDL_OpenFont* call adds two parameters to the end: 1. unsigned int hdpi: specifies the DPI resolution along the horizontal axis 2. unsigned int vdpi: specifies the DPI resolution along the vertical axis Both parameters are passed directly into FreeType, which processes them as such: * if both hdpi and vdpi are 0, then FreeType will use its default DPI of 72 * if only hdpi, or only vdpi, is 0, then FreeType will use the non-zero value for both hdpi and vdpi. For example, if hdpi is 0 and vdpi is 144, FreeType will use 144 DPI on both axes. * if both hdpi and vdpi are NOT 0, then FreeType will use the DPI resolutions as specified, along their respective axes. This addition requires no modifications to FreeType 2.x itself, and does not modify any existing SDL_ttf API (for source and binary level compatibility).