qf/quakeforge
0
0
Fork 0
mirror of https://git.code.sf.net/p/quake/quakeforge synced 2024-12-18 16:42:07 +00:00
Code Issues Projects Releases Packages Wiki Activity
quakeforge/include/QF/ui/passage.h

67 lines
1.7 KiB
C
Raw Normal View History

[ui] Add a sub-system for parsing text passages A passage object has a list of all the text objects in the given string, where the objects represent either white space or "words", as well as a view_t object representing the entire passage, with paragraphs split into child views of the passage view, and each paragraph has a child view for every text/space object in the paragraph. Paragraphs are split by '\n' (not included in any object). White space is grouped into clumps such that multiple adjacent spaces form a single object. The standard ASCII space (0x20) and all of the Unicode characters marked "WS;<compat> 0020" are counted as white space. Unless a white space object is the first in the paragraph, its view is marked for suppression by the view flow code. Contiguous non-white space characters are grouped into single objects, and their views are not suppressed. All text object views (both white space and "word") have their data pointer set to the psg_text_t object representing the text for that view. This should be suitable for simple text-mode unattributed display. More advanced rendering would probably want to create suitable objects and set the view data pointers to those objects. No assumption is made about text direction. Passage and paragraph views need to have their primary axis sizes set appropriately, as well as their resize flags. Their xlen and ylen are both set to 10, and xpos,ypos is 0,0. Paragraph views need their setgeometry pointer set to the appropriate view_flow_* function. However, they are set up to have their secondary axis set automatically when flowed. Text object views are set up for automatic flowing: grav_flow, 0,0 for xpos,ypos. However, xlen and ylen are also both 0, so need to be set by the renderer before attempting to flow the text.
2022-09-30 10:05:18 +00:00
/*
passage.h
Text passage formatting.
Copyright (C) 2022 Bill Currie <bill@taniwha.org>
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:
Free Software Foundation, Inc.
59 Temple Place - Suite 330
Boston, MA 02111-1307, USA
*/
#ifndef __QF_ui_passage_h
#define __QF_ui_passage_h
#include <stdint.h>
/** \defgroup passage Text passages
\ingroup utils
*/
///@{
[ui] Set passage text object start and size The text object covering the whole passage was not being initialized, thus center print tried to print rubbish when (incorrectly) printing the entire message.
2022-11-04 06:26:01 +00:00
enum {
passage_type_text_obj,
passage_type_count
};
[ui] Add a sub-system for parsing text passages A passage object has a list of all the text objects in the given string, where the objects represent either white space or "words", as well as a view_t object representing the entire passage, with paragraphs split into child views of the passage view, and each paragraph has a child view for every text/space object in the paragraph. Paragraphs are split by '\n' (not included in any object). White space is grouped into clumps such that multiple adjacent spaces form a single object. The standard ASCII space (0x20) and all of the Unicode characters marked "WS;<compat> 0020" are counted as white space. Unless a white space object is the first in the paragraph, its view is marked for suppression by the view flow code. Contiguous non-white space characters are grouped into single objects, and their views are not suppressed. All text object views (both white space and "word") have their data pointer set to the psg_text_t object representing the text for that view. This should be suitable for simple text-mode unattributed display. More advanced rendering would probably want to create suitable objects and set the view data pointers to those objects. No assumption is made about text direction. Passage and paragraph views need to have their primary axis sizes set appropriately, as well as their resize flags. Their xlen and ylen are both set to 10, and xpos,ypos is 0,0. Paragraph views need their setgeometry pointer set to the appropriate view_flow_* function. However, they are set up to have their secondary axis set automatically when flowed. Text object views are set up for automatic flowing: grav_flow, 0,0 for xpos,ypos. However, xlen and ylen are also both 0, so need to be set by the renderer before attempting to flow the text.
2022-09-30 10:05:18 +00:00
typedef struct psg_text_s {
/// beginning of text for this segment relative to passage_t.text
uint32_t text;
/// length of text segment in bytes rather than chars as text may be utf-8
uint32_t size;
} psg_text_t;
typedef struct passage_s {
const char *text; ///< Not owned by passage
[ui] Update passage code to use an ECS hierarchy It's not quite complete in that entities need to be created for the objects, and passage text object might get additional components in the hierarchy, but the direct use of views has been replaced by the use of a hierarchy object with the same tree structure, and now has text objects for paragraphs and the entire passage.
2022-10-27 10:47:10 +00:00
struct ecs_registry_s *reg; ///< Owning ECS registry
[ecs] Move href_comp into hierarchy_t This means that the component id used for hierarchy references must be passed to Hierarchy_New and Hierarchy_Copy, but does all an entity to have more than one hierarchy, which is useful for canvases (hierarchies of views) in the 3d world (the canvas root would have a 3d hierarchy reference and a 2d (view) hierarchy reference).
2022-12-11 15:20:20 +00:00
uint32_t href_comp; ///< Component for passage hierarcy reference
[ui] Update passage code to use an ECS hierarchy It's not quite complete in that entities need to be created for the objects, and passage text object might get additional components in the hierarchy, but the direct use of views has been replaced by the use of a hierarchy object with the same tree structure, and now has text objects for paragraphs and the entire passage.
2022-10-27 10:47:10 +00:00
struct hierarchy_s *hierarchy; ///< hierarchy of text objects
[ui] Add a sub-system for parsing text passages A passage object has a list of all the text objects in the given string, where the objects represent either white space or "words", as well as a view_t object representing the entire passage, with paragraphs split into child views of the passage view, and each paragraph has a child view for every text/space object in the paragraph. Paragraphs are split by '\n' (not included in any object). White space is grouped into clumps such that multiple adjacent spaces form a single object. The standard ASCII space (0x20) and all of the Unicode characters marked "WS;<compat> 0020" are counted as white space. Unless a white space object is the first in the paragraph, its view is marked for suppression by the view flow code. Contiguous non-white space characters are grouped into single objects, and their views are not suppressed. All text object views (both white space and "word") have their data pointer set to the psg_text_t object representing the text for that view. This should be suitable for simple text-mode unattributed display. More advanced rendering would probably want to create suitable objects and set the view data pointers to those objects. No assumption is made about text direction. Passage and paragraph views need to have their primary axis sizes set appropriately, as well as their resize flags. Their xlen and ylen are both set to 10, and xpos,ypos is 0,0. Paragraph views need their setgeometry pointer set to the appropriate view_flow_* function. However, they are set up to have their secondary axis set automatically when flowed. Text object views are set up for automatic flowing: grav_flow, 0,0 for xpos,ypos. However, xlen and ylen are also both 0, so need to be set by the renderer before attempting to flow the text.
2022-09-30 10:05:18 +00:00
} passage_t;
[ui] Make passage objects reusable I had intended to do this for a while, but now that I want it for center print strings, it was time to make the change.
2022-11-04 04:06:20 +00:00
void Passage_ParseText (passage_t *passage, const char *text);
[ecs] Move href_comp into hierarchy_t This means that the component id used for hierarchy references must be passed to Hierarchy_New and Hierarchy_Copy, but does all an entity to have more than one hierarchy, which is useful for canvases (hierarchies of views) in the 3d world (the canvas root would have a 3d hierarchy reference and a 2d (view) hierarchy reference).
2022-12-11 15:20:20 +00:00
passage_t *Passage_New (struct ecs_registry_s *reg, uint32_t href_comp);
[ui] Add a sub-system for parsing text passages A passage object has a list of all the text objects in the given string, where the objects represent either white space or "words", as well as a view_t object representing the entire passage, with paragraphs split into child views of the passage view, and each paragraph has a child view for every text/space object in the paragraph. Paragraphs are split by '\n' (not included in any object). White space is grouped into clumps such that multiple adjacent spaces form a single object. The standard ASCII space (0x20) and all of the Unicode characters marked "WS;<compat> 0020" are counted as white space. Unless a white space object is the first in the paragraph, its view is marked for suppression by the view flow code. Contiguous non-white space characters are grouped into single objects, and their views are not suppressed. All text object views (both white space and "word") have their data pointer set to the psg_text_t object representing the text for that view. This should be suitable for simple text-mode unattributed display. More advanced rendering would probably want to create suitable objects and set the view data pointers to those objects. No assumption is made about text direction. Passage and paragraph views need to have their primary axis sizes set appropriately, as well as their resize flags. Their xlen and ylen are both set to 10, and xpos,ypos is 0,0. Paragraph views need their setgeometry pointer set to the appropriate view_flow_* function. However, they are set up to have their secondary axis set automatically when flowed. Text object views are set up for automatic flowing: grav_flow, 0,0 for xpos,ypos. However, xlen and ylen are also both 0, so need to be set by the renderer before attempting to flow the text.
2022-09-30 10:05:18 +00:00
void Passage_Delete (passage_t *passage);
int Passage_IsSpace (const char *text) __attribute__((pure));
///@}
#endif//__QF_ui_passage_h
Reference in a new issue Copy permalink