This repository has been archived on 2023-10-09. You can view files and clone it, but cannot push or open issues or pull requests.
Files
blender-archive/source/blender/blenfont/BLF_api.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

306 lines
11 KiB
C++
Raw Normal View History

/*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software Foundation,
2010-02-12 13:34:04 +00:00
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
*
* The Original Code is Copyright (C) 2009 Blender Foundation.
* All rights reserved.
*/
/** \file
* \ingroup blf
2011-02-27 20:42:42 +00:00
*/
#pragma once
#include "BLI_compiler_attrs.h"
#include "BLI_sys_types.h"
2020-03-02 15:34:17 +01:00
#ifdef __cplusplus
extern "C" {
#endif
/* enable this only if needed (unused circa 2016) */
#define BLF_BLUR_ENABLE 0
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
struct ColorManagedDisplay;
struct ResultBLF;
struct rctf;
struct rcti;
2.5: Text Editor back. There was very little structure in this code, using many globals and duplicated code. Now it should be better structured. Most things should work, the main parts that are not back yet are the python plugins and markers. Notes: * Blenfont is used for drawing the text, nicely anti-aliased. * A monospace truetype font was added, since that is needed for the text editor. It's Bitstream Vera Sans Mono. This is the default gnome terminal font, but it doesn't fit entirely well with the other font I think, can be changed easily of course. * Clipboard copy/cut/paste now always uses the system clipboard, the code for the own cut buffer was removed. * The interface buttons should support copy/cut/paste again now as well. * WM_clipboard_text_get/WM_clipboard_text_set were added to the windowmanager code. * Find panel is now a kind of second header, instead of a panel. This needs especially a way to start editing the text field immediately on open still. * Operators are independent of the actual space when possible, was a bit of puzzling but got it solved nice with notifiers, and some lazy init for syntax highlight in the drawing code. * RNA was created for the text editor space and used for buttons. * Operators: * New, Open, Reload, Save, Save As, Make Internal * Run Script, Refresh Pyconstraints * Copy, Cut, Paste * Convert Whitespace, Uncomment, Comment, Indent, Unindent * Line Break, Insert * Next Marker, Previous Marker, Clear All Markers, Mark All * Select Line, Select All * Jump, Move, Move Select, Delete, Toggle Overwrite * Scroll, Scroll Bar, Set Cursor, Line Number * Find and Replace, Find, Replace, Find Set Selected, Replace Set Selected * To 3D Object * Resolve Conflict
2009-02-28 23:33:35 +00:00
int BLF_init(void);
void BLF_exit(void);
void BLF_cache_clear(void);
/* Loads a font, or returns an already loaded font and increments its reference count. */
int BLF_load(const char *name) ATTR_NONNULL();
int BLF_load_mem(const char *name, const unsigned char *mem, int mem_size) ATTR_NONNULL();
int BLF_load_unique(const char *name) ATTR_NONNULL();
int BLF_load_mem_unique(const char *name, const unsigned char *mem, int mem_size) ATTR_NONNULL();
void BLF_unload(const char *name) ATTR_NONNULL();
void BLF_unload_id(int fontid);
/* Check if font supports a particular glyph. */
bool BLF_has_glyph(int fontid, unsigned int unicode);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
/* Attach a file with metrics information from memory. */
void BLF_metrics_attach(int fontid, unsigned char *mem, int mem_size);
void BLF_aspect(int fontid, float x, float y, float z);
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
void BLF_position(int fontid, float x, float y, float z);
void BLF_size(int fontid, int size, int dpi);
/* goal: small but useful color API */
void BLF_color4ubv(int fontid, const unsigned char rgba[4]);
void BLF_color3ubv(int fontid, const unsigned char rgb[3]);
void BLF_color3ubv_alpha(int fontid, const unsigned char rgb[3], unsigned char alpha);
Add support for tiled images and the UDIM naming scheme This patch contains the work that I did during my week at the Code Quest - adding support for tiled images to Blender. With this patch, images now contain a list of tiles. By default, this just contains one tile, but if the source type is set to Tiled, the user can add additional tiles. When acquiring an ImBuf, the tile to be loaded is specified in the ImageUser. Therefore, code that is not yet aware of tiles will just access the default tile as usual. The filenames of the additional tiles are derived from the original filename according to the UDIM naming scheme - the filename contains an index that is calculated as (1001 + 10*<y coordinate of the tile> + <x coordinate of the tile>), where the x coordinate never goes above 9. Internally, the various tiles are stored in a cache just like sequences. When acquired for the first time, the code will try to load the corresponding file from disk. Alternatively, a new operator can be used to initialize the tile similar to the New Image operator. The following features are supported so far: - Automatic detection and loading of all tiles when opening the first tile (1001) - Saving all tiles - Adding and removing tiles - Filling tiles with generated images - Drawing all tiles in the Image Editor - Viewing a tiled grid even if no image is selected - Rendering tiled images in Eevee - Rendering tiled images in Cycles (in SVM mode) - Automatically skipping loading of unused tiles in Cycles - 2D texture painting (also across tiles) - 3D texture painting (also across tiles, only limitation: individual faces can not cross tile borders) - Assigning custom labels to individual tiles (drawn in the Image Editor instead of the ID) - Different resolutions between tiles There still are some missing features that will be added later (see T72390): - Workbench engine support - Packing/Unpacking support - Baking support - Cycles OSL support - many other Blender features that rely on images Thanks to Brecht for the review and to all who tested the intermediate versions! Differential Revision: https://developer.blender.org/D3509
2019-12-12 16:06:08 +01:00
void BLF_color4ub(
int fontid, unsigned char r, unsigned char g, unsigned char b, unsigned char alpha);
void BLF_color3ub(int fontid, unsigned char r, unsigned char g, unsigned char b);
void BLF_color4f(int fontid, float r, float g, float b, float a);
void BLF_color4fv(int fontid, const float rgba[4]);
void BLF_color3f(int fontid, float r, float g, float b);
void BLF_color3fv_alpha(int fontid, const float rgb[3], float alpha);
2020-10-26 15:59:08 +11:00
/* Also available: `UI_FontThemeColor(fontid, colorid)`. */
/* Set a 4x4 matrix to be multiplied before draw the text.
* Remember that you need call BLF_enable(BLF_MATRIX)
* to enable this.
*
* The order of the matrix is like GL:
2012-03-09 18:28:30 +00:00
*
* | m[0] m[4] m[8] m[12] |
* | m[1] m[5] m[9] m[13] |
* | m[2] m[6] m[10] m[14] |
* | m[3] m[7] m[11] m[15] |
*/
void BLF_matrix(int fontid, const float m[16]);
2020-10-26 15:59:08 +11:00
/* Batch draw-calls together as long as
* the model-view matrix and the font remain unchanged. */
void BLF_batch_draw_begin(void);
void BLF_batch_draw_flush(void);
void BLF_batch_draw_end(void);
/* Draw the string using the current font. */
void BLF_draw_ex(int fontid, const char *str, size_t len, struct ResultBLF *r_info)
ATTR_NONNULL(2);
void BLF_draw(int fontid, const char *str, size_t len) ATTR_NONNULL(2);
void BLF_draw_ascii_ex(int fontid, const char *str, size_t len, struct ResultBLF *r_info)
ATTR_NONNULL(2);
void BLF_draw_ascii(int fontid, const char *str, size_t len) ATTR_NONNULL(2);
int BLF_draw_mono(int fontid, const char *str, size_t len, int cwidth) ATTR_NONNULL(2);
typedef bool (*BLF_GlyphBoundsFn)(const char *str,
const size_t str_step_ofs,
const struct rcti *glyph_step_bounds,
const int glyph_advance_x,
const struct rctf *glyph_bounds,
const int glyph_bearing[2],
void *user_data);
void BLF_boundbox_foreach_glyph_ex(int fontid,
const char *str,
size_t len,
BLF_GlyphBoundsFn user_fn,
void *user_data,
struct ResultBLF *r_info) ATTR_NONNULL(2);
void BLF_boundbox_foreach_glyph(int fontid,
const char *str,
size_t len,
BLF_GlyphBoundsFn user_fn,
void *user_data) ATTR_NONNULL(2);
/* Get the string byte offset that fits within a given width */
size_t BLF_width_to_strlen(int fontid, const char *str, size_t len, float width, float *r_width)
ATTR_NONNULL(2);
/* Same as BLF_width_to_strlen but search from the string end */
size_t BLF_width_to_rstrlen(int fontid, const char *str, size_t len, float width, float *r_width)
ATTR_NONNULL(2);
/* This function return the bounding box of the string
* and are not multiplied by the aspect.
*/
void BLF_boundbox_ex(int fontid,
const char *str,
size_t len,
struct rctf *box,
struct ResultBLF *r_info) ATTR_NONNULL(2);
void BLF_boundbox(int fontid, const char *str, size_t len, struct rctf *box) ATTR_NONNULL();
/* The next both function return the width and height
* of the string, using the current font and both value
* are multiplied by the aspect of the font.
*/
float BLF_width_ex(int fontid, const char *str, size_t len, struct ResultBLF *r_info)
ATTR_WARN_UNUSED_RESULT ATTR_NONNULL(2);
float BLF_width(int fontid, const char *str, size_t len) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
float BLF_height_ex(int fontid, const char *str, size_t len, struct ResultBLF *r_info)
ATTR_WARN_UNUSED_RESULT ATTR_NONNULL(2);
float BLF_height(int fontid, const char *str, size_t len) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
/* Return dimensions of the font without any sample text. */
int BLF_height_max(int fontid) ATTR_WARN_UNUSED_RESULT;
float BLF_width_max(int fontid) ATTR_WARN_UNUSED_RESULT;
float BLF_descender(int fontid) ATTR_WARN_UNUSED_RESULT;
float BLF_ascender(int fontid) ATTR_WARN_UNUSED_RESULT;
/* The following function return the width and height of the string, but
* just in one call, so avoid extra freetype2 stuff.
*/
void BLF_width_and_height(int fontid, const char *str, size_t len, float *r_width, float *r_height)
ATTR_NONNULL();
/* For fixed width fonts only, returns the width of a
* character.
*/
float BLF_fixed_width(int fontid) ATTR_WARN_UNUSED_RESULT;
/* By default, rotation and clipping are disable and
* have to be enable/disable using BLF_enable/disable.
*/
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
void BLF_rotation(int fontid, float angle);
void BLF_clipping(int fontid, float xmin, float ymin, float xmax, float ymax);
void BLF_wordwrap(int fontid, int wrap_width);
#if BLF_BLUR_ENABLE
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
void BLF_blur(int fontid, int size);
#endif
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
void BLF_enable(int fontid, int option);
void BLF_disable(int fontid, int option);
/* Shadow options, level is the blur level, can be 3, 5 or 0 and
* the other argument are the rgba color.
* Take care that shadow need to be enable using BLF_enable!!!
*/
void BLF_shadow(int fontid, int level, const float rgba[4]) ATTR_NONNULL(3);
/* Set the offset for shadow text, this is the current cursor
* position plus this offset, don't need call BLF_position before
* this function, the current position is calculate only on
* BLF_draw, so it's safe call this whenever you like.
*/
BugFix: [#20854] PROPERTIES STAMP: Rendering stamp flickers in output renders Blenfont was not thread safe, that is why one thread can change the font properties (size, dpi, color, etc) at the same time that the stamp draw on the image, and then the problem. To make blenfont thread safe I have to change two important things: 1) Every BLF_* function take one argument, the font id. 2) We have two new function to make font "thread safe": BLF_load_unique BLF_load_mem_unique This two function are for case like stamp, that need and own font that don't share the glyph cache, so can draw without problem in a different thread. Why the BLF_*_unique function ? Because blenfont keep only one copy of a font and keep a list of "glyph cache". Every glyph cache have size and dpi, so if two different thread access the same font at the same time, they can change value and finish with something like the stamp problem. Why don't remove the glyph cache ? Because if we do that, we finish with a font object for every size and dpi, and the stamp is really a special case that happen in the rendering process, so I really thing is better keep the glyph cache and make this two new function to handle this special case. (When I say "font object" I mean have the same freetype font multiple times just to have differents size and dpi) As Matt point we still can have one case that two thread access the BLF_*_unique function at the same time, but I am looking to fix this with some class of thread lock. For now I test and work fine, so if some one found problem, please let me know. Campbell I have to change the python api (python/generic/blf_api.c) to the new syntax, so maybe you can take a look at this.
2010-04-22 10:56:45 +00:00
void BLF_shadow_offset(int fontid, int x, int y);
/* Set the buffer, size and number of channels to draw, one thing to take care is call
* this function with NULL pointer when we finish, for example:
*
* BLF_buffer(my_fbuf, my_cbuf, 100, 100, 4, true, NULL);
*
* ... set color, position and draw ...
*
* BLF_buffer(NULL, NULL, NULL, 0, 0, false, NULL);
*/
Color Management, Stage 2: Switch color pipeline to use OpenColorIO Replace old color pipeline which was supporting linear/sRGB color spaces only with OpenColorIO-based pipeline. This introduces two configurable color spaces: - Input color space for images and movie clips. This space is used to convert images/movies from color space in which file is saved to Blender's linear space (for float images, byte images are not internally converted, only input space is stored for such images and used later). This setting could be found in image/clip data block settings. - Display color space which defines space in which particular display is working. This settings could be found in scene's Color Management panel. When render result is being displayed on the screen, apart from converting image to display space, some additional conversions could happen. This conversions are: - View, which defines tone curve applying before display transformation. These are different ways to view the image on the same display device. For example it could be used to emulate film view on sRGB display. - Exposure affects on image exposure before tone map is applied. - Gamma is post-display gamma correction, could be used to match particular display gamma. - RGB curves are user-defined curves which are applying before display transformation, could be used for different purposes. All this settings by default are only applying on render result and does not affect on other images. If some particular image needs to be affected by this transformation, "View as Render" setting of image data block should be set to truth. Movie clips are always affected by all display transformations. This commit also introduces configurable color space in which sequencer is working. This setting could be found in scene's Color Management panel and it should be used if such stuff as grading needs to be done in color space different from sRGB (i.e. when Film view on sRGB display is use, using VD16 space as sequencer's internal space would make grading working in space which is close to the space using for display). Some technical notes: - Image buffer's float buffer is now always in linear space, even if it was created from 16bit byte images. - Space of byte buffer is stored in image buffer's rect_colorspace property. - Profile of image buffer was removed since it's not longer meaningful. - OpenGL and GLSL is supposed to always work in sRGB space. It is possible to support other spaces, but it's quite large project which isn't so much important. - Legacy Color Management option disabled is emulated by using None display. It could have some regressions, but there's no clear way to avoid them. - If OpenColorIO is disabled on build time, it should make blender behaving in the same way as previous release with color management enabled. More details could be found at this page (more details would be added soon): http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.64/Color_Management -- Thanks to Xavier Thomas, Lukas Toene for initial work on OpenColorIO integration and to Brecht van Lommel for some further development and code/ usecase review!
2012-09-15 10:05:07 +00:00
void BLF_buffer(int fontid,
float *fbuf,
unsigned char *cbuf,
int w,
int h,
int nch,
struct ColorManagedDisplay *display);
/* Set the color to be used for text. */
void BLF_buffer_col(int fontid, const float rgba[4]) ATTR_NONNULL(2);
/* Draw the string into the buffer, this function draw in both buffer,
* float and unsigned char _BUT_ it's not necessary set both buffer, NULL is valid here.
*/
void BLF_draw_buffer_ex(int fontid, const char *str, size_t len, struct ResultBLF *r_info)
ATTR_NONNULL(2);
void BLF_draw_buffer(int fontid, const char *str, size_t len) ATTR_NONNULL(2);
/* Add a path to the font dir paths. */
void BLF_dir_add(const char *path) ATTR_NONNULL();
/* Remove a path from the font dir paths. */
void BLF_dir_rem(const char *path) ATTR_NONNULL();
/* Return an array with all the font dir (this can be used for filesel) */
char **BLF_dir_get(int *ndir) ATTR_WARN_UNUSED_RESULT ATTR_NONNULL();
/* Free the data return by BLF_dir_get. */
void BLF_dir_free(char **dirs, int count) ATTR_NONNULL();
/* blf_thumbs.c */
void BLF_thumb_preview(const char *filename,
const char **draw_str,
const char **i18n_draw_str,
const unsigned char draw_str_lines,
const float font_color[4],
const int font_size,
unsigned char *buf,
int w,
int h,
int channels) ATTR_NONNULL();
/* blf_default.c */
void BLF_default_dpi(int dpi);
void BLF_default_set(int fontid);
int BLF_default(void); /* get default font ID so we can pass it to other functions */
/* Draw the string using the default font, size and dpi. */
void BLF_draw_default(float x, float y, float z, const char *str, size_t len) ATTR_NONNULL();
void BLF_draw_default_ascii(float x, float y, float z, const char *str, size_t len) ATTR_NONNULL();
/* Set size and DPI, and return default font ID. */
int BLF_set_default(void);
/* blf_font_default.c */
int BLF_load_default(const bool unique);
int BLF_load_mono_default(const bool unique);
#ifdef DEBUG
void BLF_state_print(int fontid);
#endif
/* font->flags. */
2012-05-11 16:11:52 +00:00
#define BLF_ROTATION (1 << 0)
#define BLF_CLIPPING (1 << 1)
#define BLF_SHADOW (1 << 2)
#define BLF_KERNING_DEFAULT (1 << 3)
#define BLF_MATRIX (1 << 4)
#define BLF_ASPECT (1 << 5)
#define BLF_WORD_WRAP (1 << 6)
#define BLF_MONOCHROME (1 << 7) /* no-AA */
#define BLF_HINTING_NONE (1 << 8)
#define BLF_HINTING_SLIGHT (1 << 9)
#define BLF_HINTING_FULL (1 << 10)
#define BLF_BOLD (1 << 11)
#define BLF_ITALIC (1 << 12)
#define BLF_DRAW_STR_DUMMY_MAX 1024
/* XXX, bad design */
extern int blf_mono_font;
2012-03-18 07:38:51 +00:00
extern int blf_mono_font_render; /* don't mess drawing with render threads. */
/**
* Result of drawing/evaluating the string
*/
struct ResultBLF {
/**
* Number of lines drawn when #BLF_WORD_WRAP is enabled (both wrapped and `\n` newline).
*/
int lines;
/**
* The 'cursor' position on completion (ignoring character boundbox).
*/
int width;
};
2020-03-02 15:34:17 +01:00
#ifdef __cplusplus
}
#endif