Difference between revisions of "Text-Handling in GIMP"

From GIMP GUI Redesign
Jump to: navigation, search
(starting points)
(resize)
(153 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
== Introduction ==
 +
 +
Going beyond just looking at the Text tool, this project is about the complete text handling in GIMP. Examples of what this project addresses are: typographical control to the highest degree; wrapping to paths; arbitrary vector shapes for text boxes; placement and stacking order of multiple text boxes within a layer.
 +
 
== Vision ==
 
== Vision ==
'''Text handling in GIMP'''
+
To guide all of the design work of this project, a vision was formulated for it. We combined GIMP’s [[GIMP_UI_Redesign#product_vision|product vision]] with insight into the activity and needs of core GIMP users where it comes to text, and added into the mix GIMP’s roadmap (i.e. GEGL). Boiled down to the essence, the vision is as follows:
 +
 
 +
* Text in GIMP is always part of the composition—unless it is an annotation
 +
* The canvas is not a page; there is no such thing as paging in GIMP
 +
* Text in GIMP is both for reading and used as graphical shapes; meta data in text—mark-up, semantics—are not supported
 +
 
 +
GIMP users get:
  
*Text in GIMP is always part of the composition - (unless it is an annotation)
+
* Minute control over typography and the layout of text on the canvas
*There is no such thing as paging in gimp
+
* internationalisation of text handling, for all locales supported by unicode
*Text in gimp has form and symbolic meaning, but meta levels of information in text are not supported
+
* text remains editable forever
Users get:
+
* super-fast workflow, when they are experienced
*Complete control over typography and the layout of text on the canvas
 
*unicode supported localisation of text tools
 
*editable text until they decide otherwise
 
*super-fast workflow, when they are experienced
 
  
 
== Functionality ==
 
== Functionality ==
 +
=== Field survey ===
 +
In order to compile a comprehensive list of what future text-handling in GIMP should include, we did a survey of other software packages in the field of GIMP.
 +
 +
[[Text in InDesign]]
 +
 +
[[Text in Scribus]]
 +
 +
[[Text in Photoshop]]
 +
 +
[[Text in Inkscape]]
 +
 +
Additionally a review of current text-functionality in GIMP, its technical background as well as capabilities of current or future libraries has been done.
 +
 +
[[Updated Text Functionality in Gimp 2.7.4]]
 +
 +
[[Processing of Text Input in Gimp]]
 +
 +
[[Pango features]]
 +
 +
[[Harfbuzz]]
 +
 +
'''note:''' ''just about all traits and transformations described below that can be applied to text, can be applied to:''
 +
*''a point in the text''
 +
*''a span''
 +
*''a paragraph''
 +
*''the whole text instance''
 +
*''several instances of texts''
  
=== Internationalization ===
+
=== Internationalisation ===
* full support of all Unicode content
 
* support for all OpenType features
 
 
* multiple writing systems in the same text-box
 
* multiple writing systems in the same text-box
* right to left and top-down textflow
 
  
=== Corrections ===
+
=== Annotations ===
*the text content is always accessible and editable
+
* add, edit and delete annotations
*all applied effects are kept
+
* show/hide
 +
* relate annotation to canvas
 +
* file-wide search of annotation text
 +
 
 +
=== Text box ===
 +
* add and delete text boxes
 +
* set position, size and stacking order
 +
* cut, copy + paste of boxes
 +
* wrap text to box or dynamic text box
 +
* text overflow from box to box
  
=== Quick plain text ===
+
==== Text box geometry ====
*the full-functionality text-tool is not obligatory
+
* text boxes of any shape
*simple annotations are supported (-> new tool)
+
* text (baseline, top of caps) along path
*can be inserted in an easy way
+
* alignment axis (left, right , centre) along path
 +
* box geometry transformations
  
=== Effects ===
+
=== Text ===
*stroke text (shared with vector tool)
+
* add and delete characters
*fill text (shared with vector tool)
+
* full support for all characters covered by Unicode
*all effects and filter can be applied on the text itself (see "Corrections")
+
* insert and overwrite
 +
* cut, copy + paste
 +
* mangage line-breaks, paragraphs, etc.
 +
* transformations
 +
** to upper, to lower, capitalise
 +
** rotate
 +
* execute spell check
 +
** select language (…-100s)
 +
* search + replace, for this text, whole file + all open files
 +
* rendering glyphs: fill, stroke and line style; see [http://blog.mmiworks.net/2009/07/teaching-interaction-09.html work on vector tool]
  
=== Layout ===
+
=== Rulers ===
*full control to the user on every level
+
* text specific rulers
*all this is done in the context of the overall work:
+
* grid (see [http://en.wikipedia.org/wiki/Grid_%28page_layout%29 Wikipedia on Grid page layout ] )
**the canvas
 
**the applied effects
 
  
==== Positioning ====
+
=== Typography ===
*freely positionable on the canvas
+
 
*text boxes of any shape
+
* presets can be added, edited, deleted and applied
*(rectangular) box fixed or dynamic
 
*text overflow from box to box
 
*text along path
 
*transformation tools
 
*combinations of above functions
 
*?grid (see http://en.wikipedia.org/wiki/Grid_%28page_layout%29 )
 
  
==== Typography ====
+
* manual access to all characters of a font: Glyph palette
*fine grained-control
 
*presets can be saved
 
*manual access (M) to open type (OT) features: Glyph palette
 
  
 
'''Character level'''
 
'''Character level'''
*Font family (…-100s)
+
* set font family (…-100s)
*Font variant (1-~20)
+
* set font variant (1-~20)
*size(values between 1-infinite)
+
* set size(values between 1-infinite)
*Color (GIMP color selection)
+
* set color
*Hinting (2-5)
+
* set hinting (2-5)
*Kerning (0,1)
+
* set kerning (value)
*faux bold+italics (0,1)(0,1)
+
* set tracking (value)
*underline (0,1) + (options)
+
* toggle faux bold+italics (0,1)(0,1)
*through-line (0,1) + (options)
+
* toggle underline (0,1) + (options)
*baseline shift (value)
+
* toggle through-line (0,1) + (options)
*language (…-100s)
+
* set baseline shift (value)
 +
 
 +
see the list of non script-specific [[OpenType features]] (68)
 +
examples:
 +
* historical ligatures: Some ligatures were in common use in the past, but appear anachronistic today. Some fonts include the historical forms as alternates, so they can be used for a 'period' effect.
 +
* superscript: use to automatically access the superior figures (more legible than scaled figures)
  
+ [[OpenType features]]
+
+ there are the script-specific features (also ~68)
  
*?glyph scaling (vertical and horizontal) (2 values)
+
* set glyph scaling (vertical and horizontal) (2 values)
  
 
'''line and paragraph level'''
 
'''line and paragraph level'''
*leading (value)
+
* set margins (4 values)
*tracking (value)
+
* set leading (value)
*Indent (value)
+
* set indent (value)
*alignment (justification (1 [?+4 for last line]), flush (2), center)
+
* choose alignment (justification (1 [?+4 for last line]), flush (2), center)
*inter-paragraph spacing (value)
+
* set inter-paragraph spacing (value)
*text-flow (2)
+
* choose text-flow (all 4 directions)
 
 
<!--
 
== What's NOT in it ==
 
This section cannot cover everything. Its purpose is to "draw the line".
 
*paging
 
*multi-columns
 
*??text overflow (box to box)
 
*footnotes
 
*field functions
 
*meta text (apart from Comment/Exif data)
 
*automatic creation of content (TOC, tables,…)
 
 
 
-->
 
  
 
== User scenarios ==
 
== User scenarios ==
Line 96: Line 126:
 
=== Photographer (Annotations) ===
 
=== Photographer (Annotations) ===
  
(see Scenario 1a)
+
(see [[User_Scenarios#1.a_Photo_Realistic|scenario 1a]])
 
*open file
 
*open file
 
*apply changes
 
*apply changes
 
*add text information to image
 
*add text information to image
 
**no effects, basic font+style+size
 
**no effects, basic font+style+size
 +
*place text closer to part of image the note is about
 
*on/off for annotations when wanting to work undisturbed
 
*on/off for annotations when wanting to work undisturbed
  
 
=== Creating Original Art ===
 
=== Creating Original Art ===
==== "text as graphics" ====
+
==== text as graphics ====
 
* [no-text work]
 
* [no-text work]
 
* freely define text-box-shape
 
* freely define text-box-shape
Line 121: Line 152:
 
* work on typography
 
* work on typography
 
** basic settings font family + variant + size + color
 
** basic settings font family + variant + size + color
** set paragraph or text-box layouting (e.g. alignment, justification, hyphenation)
+
** set paragraph or text-box layouting (e.g. alignment, justification, writing direction, hyphenation)
 
** fine-tune text, making use of advanced typography/OpenType and optional manual replacements
 
** fine-tune text, making use of advanced typography/OpenType and optional manual replacements
 
* move, resize, reshape, reorder boxes
 
* move, resize, reshape, reorder boxes
Line 154: Line 185:
 
evaluated tools: GIMP (2.7.4), Inkscape, Scribus, InDesign, Photoshop
 
evaluated tools: GIMP (2.7.4), Inkscape, Scribus, InDesign, Photoshop
  
 
+
=== Photographer (Annotations) ===
=== text placement ===
+
==== text placement ====
 
+
one-click or define frame first (Gimp, Photoshop, Inkscape)
one-click '''or''' define frame first (Gimp, Photoshop, Inkscape)
 
 
* + gives most flexibility  
 
* + gives most flexibility  
 
* + is easy to handle  with one button
 
* + is easy to handle  with one button
 
* + feels real. You can grab a pen, place it and start writing right away
 
* + feels real. You can grab a pen, place it and start writing right away
* - the mouse pointer is important. A Cursor I is not useful for creating a box and a + is not handy to start typing right away.  
+
the mouse pointer is important. A Cursor I is not useful for creating a box and a + is not handy to start typing right away.  
 +
 
 +
Mandatory fixed-box definition (Indesign, Scribus)
 +
* - may disturb the work-flow in a graphic tool but is appropriate for desktop publishing. In a graphic-context users should decide whether they want to break lines manually with the Enter-Button or by pre-defining a vertical border (e.g. the right and lower side of the box).
 +
 
 +
==== adding second element ====
 +
click anywhere outside the text-box
 +
*+ fast
 +
*+ text-tool does what can be expected
 +
 
 +
confirm editing, then click outside the text-box (Photoshop)
 +
*+ (see moving the box)
 +
*- gets in the way of quickly creating multiple boxes
 +
 
 +
==== basic font-style-size settings ====
 +
select tool preset and apply it:
 +
* + quick
 +
* + anytime, because applying to whole text is enough
 +
* - tussle between using a general default for every box, having to pick one every time, or taking the last-used settings
 +
 
 +
==== resize ====
 +
grab corners/sides of box and drag (GIMP, PS, Inkscape)
 +
* + quick, inside the tool
 +
 
 +
select transformation tool (Scribus)
 +
* - leaving text-work for minor adjustments
 +
 
 +
==== move ====
 +
 
 +
select move tool, then click
 +
 
 +
* - disturbs workflow
 +
 
 +
select transformation tools, then click on text (Inkscape)
 +
 
 +
* + all transformations in one place
 +
* - disturbs workflow
 +
 
 +
click and drag anywhere on the canvas, outside the text box (PS)
 +
 
 +
* + fast, basic transformations on hand
 +
 
 +
==== switch annotations on/off ====
 +
not possible in GIMP
  
 +
=== Creating Original Art ===
 +
==== text along path and custom text-box shape ====
  
forced frame-drawing (Indesign, Scribus)
+
path and text, then "merge. No text-box shape transforms (GIMP)
may disturb the work-flow in a graphic tool but is appropriate for desktop publishing. In a graphic-context user should decide whether he wants to break lines manually with the Enter-Button or by pre-defining a vertical border (e.g. the right-side end of the box).
+
* + can be done anytime
 +
* - text DOES NOT stay editable
 +
* - order things are done is mandatory: both, text and path have to exist in the first place
 +
* - also the path has to be selected in the path dialog, though the text is selected on the canvas, to attach one to the other.
  
=== family and style/variant selection ===
+
first path, then text (Photoshop)
 +
* + It feels intuitive to move text tool on or inside a path and thereby "attaching" the text to it
 +
* + one tool to place regular text, attach it to a path or wrap it to a shape
 +
* + stays editable
 +
* + warping presets can be applied anytime
 +
* + nice to define either baseline or box shape in the same way using the path tool
 +
* + option of flipping text to other side of path/use ascender instead of descender to aline with path
 +
* - no direct way to later make an already written (and formatted) text go along a path
 +
 
 +
first path then text with special text along path tool (InDesign)
 +
* + stays editable
 +
* + text boxes can be directly transformed by grabbing a corner, etc.
 +
* - no direct way to later make an already written (and formatted) text go along a path
 +
* - special tool can only be used on path anyway. PS gives a better solution
 +
 
 +
path and text, then "merge". Text-box form is part of text properties (Scribus)
 +
* + can be done anytime
 +
* + text box shape as part of text properties is really effective
 +
* + separation of path and text-box form makes sense. However, when making text go along a path the path becomes the form of the text box.
 +
* - order things are done is mandatory: both, text and path/shape have to exist in the first place
 +
 
 +
path/shape and text, then "merge" (Inkscape)
 +
* + can be done anytime
 +
* + nice universal solution, only the last step ("along path" or "flow into form") differs
 +
* + text and path always editable
 +
* - order things are done is mandatory: both, text and path/shape have to exist in the first place
 +
 
 +
==== font family and style/variant selection ====
  
 
all-in-one (Inkscape, Gimp)
 
all-in-one (Inkscape, Gimp)
Line 175: Line 280:
 
* - list grows in length by a considerable amount
 
* - list grows in length by a considerable amount
 
* - hard to tell sub-fonts of the same family and different fonts apart
 
* - hard to tell sub-fonts of the same family and different fonts apart
 
  
 
two separate selectors (Photoshop, InDesign, Scribus)
 
two separate selectors (Photoshop, InDesign, Scribus)
 
* + Good overview of families
 
* + Good overview of families
 +
* + good for work in one family
 
* - users don't see what variants exist, but have to actually select a font to get this information. This takes time when browsing through (Open Type) fonts.
 
* - users don't see what variants exist, but have to actually select a font to get this information. This takes time when browsing through (Open Type) fonts.
* -
 
  
  
two-step selection with variant as a sub-menu
+
find a middle way
* + only one selector needs less menu space
 
* + Good overview of families
 
* + browsing feels quick
 
* + one click selection
 
* - user don't see what variants exist (Mouseover helps)
 
  
 
'''Additional remarks'''
 
'''Additional remarks'''
Line 194: Line 293:
 
* An icon showing the font's type (TTF, OT, etc) helps (also visually) when browsing the font list.
 
* An icon showing the font's type (TTF, OT, etc) helps (also visually) when browsing the font list.
  
=== native font variant versus variant toggling (?faux) ===
+
==== native font variant versus variant toggling (?faux) ====
 +
 
 +
GIMP
 +
At current state GIMP does not behave in any of the ways mentioned above. Buttons for faux (presumably) b./i. exist. The display does not indicate a switch to an existent pre-defined sub-font. Also, the toggle buttons do not have any effect when a respective sub-font hast been chosen. (no double bold). A decision should be taken about the way this works and feedback needs to be give to the user.
  
 
no faux bold/italics, only font-integrated options available (Scribus)
 
no faux bold/italics, only font-integrated options available (Scribus)
 +
  
 
faux bold/italics toggles
 
faux bold/italics toggles
 +
 
if implemented an automatic switch to pre-designed (Inkscape) applies a change not in the place where user sets it. At least an indicator should be present.
 
if implemented an automatic switch to pre-designed (Inkscape) applies a change not in the place where user sets it. At least an indicator should be present.
An explicit '''faux''' b./i. switch (Photoshop) seems more intuitive and gives more control to the user (double bold).
 
  
GIMP
+
An explicit ''faux'' b./i. switch (Photoshop) seems more intuitive and gives more control to the user (double bold).
At current state GIMP does not behave in any of the ways mentioned above. Buttons for faux (presumably) b./i. exist. The display does not indicate a switch to an existent pre-defined sub-font. Also, the toggle buttons do not have any effect when a respective sub-font hast been chosen. (no double bold). A decision should be taken about the way this works and feedback needs to be give to the user.
+
 
 +
==== transformations of text(-box) (e.g. for perspective) ====
 +
select desired transformation tool, apply
 +
* + universal
 +
* - only applicable to text. box is not an object itself
 +
* - text is non editable afterwards (only if transformation is undone)
 +
 
 +
Photoshop
 +
* simple shape:
 +
** scaling changes box
 +
** rotating changes text+box
 +
* + stays editable
 +
 
 +
* complex shape:
 +
** original shape is copied to a text shape
 +
** transformations always effect text+box
 +
* - easy to lose the ability to edit text
 +
 
 +
Inkscape
 +
* scaling changes text (and box)
 +
* rotating changes only text
 +
* other transformations change text+box
 +
 
 +
==== Advanced Typography ====
 +
''Photoshop (and InDesign)'':
 +
 
 +
The most basic settings are in a toolbar. For quick typography this does the job. The toolbar also includes a button to open the typography window.
 +
 
 +
The typography window with it's two tabs and an included menu contains all options available.
 +
The first tab shows all settings on a character level, the second one on the paragraph level. The menu hosts all the settings plus a few extra options, like a reset.
 +
 
 +
Character tab:
 +
font family and variant come first. The next section contains metrical adjustmens of font size, leading (line-spacing), tracking (letter-spacing) and kerning. Whereas the former three work on any selection, kerning needs to be adjusted for individual pairs of letters. Therefore the cursor has to be placed between the two letters, to make the the kerning setting accessible.
 +
 
 +
* - confusing that entry boxes show unit ( Pt ) but this is not changeable.
 +
 
 +
The next section allows for vertical and horizontal glyph scaling, plus setting a baseline offset and selecting a text color.  
 +
 
 +
Next comes a row of buttons for toggling faux bold, italics, capitals, small capitals, superscript, subscript, underline and through-line. Last comes a language selector and a drop-down menu to choose hinting.
 +
 
 +
Paragraph tab:
 +
All settings affect the whole paragraph.
 +
 
 +
First comes a line of alignment buttons. Justification options are greyed out, when text is in a dynamic shape.
 +
 
 +
The next section allows for setting a first line indent, as well as general left or right indents and spacing before and after the paragraph.
 +
 
 +
 
 +
Overall:
 +
* + the tabs are a functional way of using rare space
 +
* + tabs provide better overview through structurization
 +
* + the grouping is mostly understandable
 +
 
 +
 
 +
''Inkscape'':
 +
 
 +
Inkscape offers a toolbar and an extra window for text-settings.
 +
 
 +
Extra Window
 +
 
 +
Editing tab: Plain text
 +
 
 +
Font tab: Select font family, variant and size. Also alignment, text-flow and line-spacing. A preview is in the bottom line.
 +
 
 +
Toolbar
 +
 
 +
font family, no variant (!), size, bold and italics, alignment, super- and subscript. Leading, tracking, spacing between words, kerning, vertical shift, glyph rotation and text-flow.
  
  
=== Advanced Typography ===
+
* + clear icons
 +
* + good control for metric settings
 +
* + glyph palette
 +
* - distribution of settings
  
  
=== Open Type ===
+
OpenType is only available in Photoshop (basic functionality) and InDesign (extensive functionality). All Options are accessed via a menu in the typography window. They are presented as as on/off switches.  
OpenType is only available in Photoshop (basic functionality) and InDesign (extensive functionality). All Options are accessed via a menu offering them as on/off switches.  
 
  
 
* + too much for direct access via toolbox
 
* + too much for direct access via toolbox
 
* - when wanting to select more than one, users have to open the menu again and again.  
 
* - when wanting to select more than one, users have to open the menu again and again.  
  
=== placement of tool options ===
+
Checkboxes seem to solve the above issue
 +
 
 +
==== tool presets/styles ====
 +
 
 +
tool presets (GIMP, Photoshop)
 +
* + give users the option to customize and build a library of often used settings
 +
* + integrate well with the rest of the program. Universal solution
 +
* - users cannot apply them to already existing text, eliminating a big number of possible use cases. In GIMP one can apply them to a selected text, but only to the whole box. (Also, the behavior is not always predictable: Switching between tool presets changes the text orientation. Bug?)
 +
 
 +
text styles (Scribus, InDesign)
 +
* + give users the option to customize and build a library of often used settings
 +
* + always applicable, making it possible to write first and format later with some predefined styles. This gives more freedom.
 +
* + can be put next to the text settings, giving quick access and making it easy to see they take effect
 +
* - need toolbox space (toolbox, because they only make sense when quickly accessible)
 +
 
 +
Inkscape does not save any user settings in the text tool besides setting a default.
  
toolbox/toolbar
+
=== Icon Design ===
 +
==== glyph palette ====
 +
not available (GIMP, Photoshop)
 +
* - A switch to other tools takes time to open the tool and searching the desired font again
 +
 
 +
=== Web Images Production ===
 +
settings not applicable to several texts (unless style-markup exists)
 +
 
 +
 
 +
=== General ===
 +
==== placement of tool options ====
 +
 
 +
tool options (on side)/ toolbar (on top)
 
* + more (all) options on screen
 
* + more (all) options on screen
 
* + no extra dialog
 
* + no extra dialog
Line 231: Line 429:
 
* + comes handy in cases where effects/layouting disturb editing.
 
* + comes handy in cases where effects/layouting disturb editing.
 
* - Having some of the formatting options only available in external dialog (Inkscape) is bad for the workflow.  
 
* - Having some of the formatting options only available in external dialog (Inkscape) is bad for the workflow.  
* - Changes are not in the context of the work
+
* - Changes are not in the context of the work (no live update on canvas)
  
GIMP
+
GIMP currently uses a combination of toolbox, extra window and heads-up-display
Gimp currently uses a combination of toolbox, extra window and heads-up-display
 
 
* + separable radius of effect: toolbox for whole text-box, hud for selected text.  
 
* + separable radius of effect: toolbox for whole text-box, hud for selected text.  
 
* - above also presents difficulties:  
 
* - above also presents difficulties:  
Line 240: Line 437:
 
* - a checkbox does not seem the right way to start the text-editor
 
* - a checkbox does not seem the right way to start the text-editor
  
 +
== Analysis ==
  
=== tool presets/styles ===
+
In GIMP text handling there are
Inkscape does not save any user settings in the text tool besides setting a default.  
+
* text, as text itself,
 +
* vector object container and
 +
* paths, which modify text.
  
 +
Text (down to glyph level),  vector container and path must all be able to be manipulated individually.
  
tool presets (GIMP, Photoshop)
+
=== Text ===
* + give users the option to customize and build a library of often used settings
+
* Text, as text itself
* + integrate well with the rest of the program. Universal solution
+
** it has no container
* - They are not where the text settings are made
+
** but a position
* - users cannot apply them to already existing text, eliminating a big number of possible use cases. In GIMP one can apply them to a selected text, but only to the whole box. (Also, the behavior is not always predictable: Switching between tool presets changes the text orientation. Bug?)
+
** and typographical parameters
 +
 
 +
==== Typography Overview ====
 +
 
 +
[[Image:Typography_overview.jpg]]
 +
 
 +
(missing: inter-paragraph spacing, text-flow)
 +
 
 +
These are all properties that are part of the text itself and do not need an additional object (e.g. a container) to take effect.
 +
 
 +
The followig are text properties but need an external object to take effect:
 +
 
 +
* margins (debatable whether left and top margin have an effect in text without box. They could shift it according to the original coordinate.)
 +
* justification
 +
 
 +
=== Vector object container ===
  
text styles (Scribus, InDesign)
+
* Vector object containers
* + give users the option to customize and build a library of often used settings
+
The text vector container spans from:
* + always applicable, making it possible to write first and format later with some predefined styles. This gives more freedom.
+
** a simple text container
* + can be put next to the text settings, giving quick access and making it easy to see they take effect
+
** to a complex geometric vector form.
* - need toolbox space (toolbox, because they only make sense when quickly accessible)
 
  
=== text along path and custom text-box shape ===
+
** the text is contained
 +
** the text layout is modified by the vector shape
 +
** it provides a reference for typographic features that depend on it. (margins, justification)
  
first path, then text (Photoshop)
+
The actual space for holding text is the inside of the vector container ''minus'' the respective margins.
* + It feels intuitive to move text tool on or inside a path and thereby "attaching" the text to it
 
* + one tool that does both
 
* + stays editable
 
* + warping presets can be applied anytime
 
* + nice to define either text line or box shape in the same way using the path tool
 
* - no direct way to later make an already written (and formatted) text go along a path
 
  
first path then text with special text along path tool (InDesign)
+
* Margins are a property of the respective paragraph.
* + stays editable
+
* They can differ between different paragraphs.
* + text boxes can be directly transformed by grabbing a corner, etc.
+
* They are not a property of the vector object.
* - no direct way to later make an already written (and formatted) text go along a path
 
* - special tool can only be used on path anyway. PS gives a better solution
 
  
path and text, then "merge". Text-box form is part of text properties (Scribus)
+
==== Glyph placement ====
* + can be done anytime
 
* + text box shape as part of text properties is really effective
 
* + separation of path and text-box form makes sense. However, when making text go along a path the path becomes the form of the text box.
 
* - text along path is not really convenient to use. selecting both, then chosing the menu item...
 
  
path/shape and text, then "merge" (Inkscape)
+
principle: Text in vector object means nothing is outside!
* + can be done anytime
+
e.g.:A glyph can only be placed, when around it, there is enough space for ''all'' margins.
* + nice universal solution, only the last step ("along path" or "flow into form") differs
 
* + text and path always editable
 
* - not really convenient to use. selecting both, then chosing the menu item...
 
  
path and text, then "merge. No text-box shape transforms (GIMP)
+
? What is first set: the first baseline or the first glyph?
* + can be done anytime
 
* - DOES NOT stay editable
 
* - not really convenient to use. selecting both, then chosing the menu item...
 
* - also the path has to be selected in the path dialog, though the text is selected on the canvas, to attach one to the other.
 
  
== Analysis ==
+
A glyph is moved to the next line, when
=== define shape/flow/placement ===
+
the dynamic text box and the basic rectangular box are created with the text tool itself. The new GIMP handles for resizing/transforming should be present. (compare: student team 1: http://blog.mmiworks.net/2009/07/teaching-interaction-09.html )
+
* placement of the glyph on the current line
 +
leads to
 +
* its body dimensions (or outline/blackbox) ''plus'' the margins
 +
being on the edge or outside of
 +
* the vector object container
  
Advanced shapes are defined with the new vector tool and transformation or resizing is done accordingly. Existing text-elements can then be put in this shape or a new one may be started inside.
 
  
The same applies to text along path (correct name: ''baseline along vector'').  
+
* Text runs endlessly
 +
* The placement described above refers to visibility
 +
* After the last possible (e.g. bottom-right) glyph has been placed, text can still be entered and is stored as part of the text object.
 +
* It can become visible through
 +
** increase of vector object size
 +
** decrease of margins
 +
** decrease of font-size or general in-text spacing
 +
** definition of a next vector object container for text overflow
 +
** etc.
  
Also a new mode, namely ''start margin along vector'' is needed (1), which does also provide for a way of rotating text. (e.g. a straight diagonal vector) (2) and is also combineable with an advanced shape (3).
+
==== specific text-shape objects for complex shapes? ====
 +
For complex shapes the question arises whether it is the original vector object that contains the text, or if a copy of it as an specific text-shape is better suited.
  
(1) [[Image:Margin_vector.png]] (2) [[Image:Margin_rotate.png]] (3) [[Image:Margin_vector_shape.png]]
+
pro original vector:
 +
* unified approach
 +
* no doubling of tools
 +
* creating + later modyfing are the same
 +
* changing vector means changing text shape. This is especially important, as this starting point implies a close binding of text to the canvas setting.  
 +
* if users want to losen this binding, a simple copy of the original vector is easily created
  
Vertical text (!= rotation) is missing.
+
pro specific text-shape
 +
* independence of vector
 +
* possibility of adding text-specific controls
  
 +
==== container for complex shapes? ====
  
This is further evaluated in [[Geometry of text placement]]
+
a rectangular container around complex shapes provides advantages
 +
* specification of left and right
 +
* provides a good way of keeping original vectors as shapes while still providing text-specific controls to it thereby adressing some of the points above.
  
=== presets/styles ===
+
==== holes/wrapping around vectors ====
a set of user-saved settings needs to be applicable (1) after creating a text-element and (2) to parts of a text-element. Both is not possible with current tool-presets. Whether text should reflect later changes in the according style is subject to discussion, but probably out of GIMP's focus.
+
text can not only be inside a vector shape but also around a vector shape.  
  
=== control/menu behavior ===
+
* property of the vector object
 +
* linked to as many instances of text as wanted
 +
* also vector shapes serving as text containers can have this property towards other text instances
 +
* Users need to be able to explicitly control which text instances the vector object influences.
  
==== editor ====
+
=== Paths ===
The editor gives one-click access to a plain view of the text. All layouting apart from line-breaks and justification (both depending on the size of the text-element) needs to be visible.
+
* Path modify text, or more specifically
 +
** the baseline(s)
 +
** the alignment-axis
  
Any intermediate abstraction from the image (e.g. turning the background off, but keeping the abstract shape of the text element) can be realized by the user via the layers dialog.
+
**if the text is contained in a vector shape the path modifies the text- which is contained by the vector object.
 
User can always switch between text-editor and canvas editing and changes made in the editor need to be displayed live on the canvas.
 
Also the editor is the place where users shouldn't miss a single bit of text-functionality.
 
  
==== toolbox and HUD ====
 
The toolbox settings do not consider a selection made. This makes sense in the logic of treating the text-element as a whole but easily gets in the way of formatting. Also the HUD (for applying changes to selected text only) does not contain all options.
 
  
If the separation in focus (where do they work) of toolbox and HUD is to be kept, HUD should receive full functionality. Alternatively both could get the same focus and HUD's purpose lies in proximity to action giving access to basic features. Doing a SelectAll before major changes should not distract the workflow.
+
==== Text along path ====
 +
* correct name: ''baseline along path''
 +
* It dissolves the straightness of baselines
  
In general, the toolbox should contain all settings that are liste above in Typography > Character level. Some features can be grouped and made accessible via a sub-menu (e.g. justification types) to save space. The button can present the current state. The grouping should be reflected in the visual order of things in the comprehensive text-editor.
+
[[Image:text_exmp_t-a.jpg]]
  
OpenType features are plentisome: Cannot be present on first level menu (maybe it suffices to have them in the menubar). However, they need to be accessible in a checkbox-manner to allow for quick switching on/off of multiple OT features.
+
The left an right side of the text are boundaries.
  
A simple glyph palette should provide manual access to all a font has to offer
+
Options: (options in brackets, defaults in italics)
 +
* Flip side (''left side''/right side)
 +
* set range on path (''whole path'')
 +
* toggle multiple lines? (''on''/off)
 +
* set reference line (descender height, ''baseline'', median, cap height, ascender height)
  
=== misc ===
+
where does new lines get added? Moving up is not in line with the coordinate thing of sole text
bold/italics could be named "manual bold/italics" and always do this. Professionals know about the possible existence of sub-fonts.
 
  
stroke text or basic effect like drop-shadows should be shared with the new vector-tool. Text is nothing else than vectors.  
+
==== Text from path ====
 +
* correct name: ''alignment axis along path''
 +
* It dissolves the parallelity of baselines.
  
for font selection a two-step mode with variant as a sub-menu should provide overview and accessibility. A preview of the font and an icon showing it's type should be implemented.
+
[[Image:text_exmp_t-f.jpg]]
  
a distinction has to be made between transformations that alter the shape of the text-element but leaving the glyph-shapes intact and transformation that affect the glyphs (e.g. 3D-perspective). Users have to be able to set the scope of the transformation.
 
  
=== effects/transformation and boundaries ===
+
Options: (options in brackets, defaults in italics)
Current situation:
+
* flip side(''left''/right side) (e.g. flip direction)
when transforming text it loses its text-property but is nevertheless still limited to the size of the original text, which was used to layout the text (as a layer boundary) (the purpose for limiting the text area may be very different from the one for limiting a layer to a certain size)
+
* set range on path (''whole path'')
 +
* ?line overlap (''on''/off)
 +
** happens with small leading values too
  
In the future this issue will gain further importance by text being always editable (and therefore layouted by the text-engine).
+
=== Combinations ===
A transformation of glyphs or stroking them alters the visual size of the text. Line-breaks and wrapping (also in advanced text-element shapes) are calculated based on the dimensions of the glyph.
 
  
A solution has to be defined on both levels, the mathematical and the visual.
+
==== Positioning ====
  
=== layers/text layers/text-elements ===
+
as positions on the canvas of text elements and properties are likely to conflict the hierarchy is as follows:
  
In accordance to the general discussion on the role of layers (see: [[Analysis#layers]] or [[Evaluation_Notes_-_Creating_Original_Art#Text]] for text use)the behavior of text layers needs to be redefined.
+
* the container
Right now every text-element created automatically creates a new layer.
+
* the path
 +
* the text itself
  
=== starting points ===
+
Position properties are not lost when not taking effect in hierarchy. When connections between objects is cut, the one lower in hierarchy returns to its own position
  
 +
==== Overview ====
  
 
{| border="1" cellpadding="5" cellspacing="0"
 
{| border="1" cellpadding="5" cellspacing="0"
 
!
 
!
!dynamic shape
+
!Sole text
!fixed basic (rectangular) shape
+
!Text in vector object container
!(any) vector shape
+
|-
 +
|'''no path'''
 +
|[[Image:Text_exmp_t-n.jpg]]
 +
* positioning by text obejct (coordinate is property)
 +
* Only two (left and top) boundaries
 +
* alignment and justification properties do not take effect
 +
* margin can only take effect on two boundaries
 +
|[[Image:Text_exmp_rv-n.jpg]]
 +
* positioning by vector object
 +
* all four boundaries available
 +
* = alignment, justification, margins, all there
 
|-
 
|-
|'''aims/scenarios'''
+
|'''along path'''
|click'n'type
+
 
  
workflow
 
  
text centered
+
|[[Image:Text_exmp_t-a.jpg]]
 +
* positioning by path
 +
* provides third (second in text flow) boundary = end of path!
 +
* Left/right alignment available
  
small amounts of text
+
|[[Image:Text_exmp_rv-a.jpg]]
 +
* positioning by vector object
 +
|-
 +
|'''From path'''
  
non-strict layouting
+
|[[Image:Text_exmp_t-f.jpg]]
 +
* positioning by path
  
area/shape is not an object as itself
+
|[[Image:Text_exmp_rv-f.jpg]]
|layout centered = placement control
+
* positioning by vector object
  
prevent/control intereference with other objects on canvas (boundaries)
 
  
use box as a shape (the box itself is s.th.)
+
|-
 +
|from+along path
  
justification
+
* options and defaults are defined by individual path modifiers
  
 +
|[[Image:Example.jpg]]
 +
* positioning by from path
  
|generally broad variety of aims
+
|[[Image:Example.jpg]]
 +
* positioning by vector object
  
free art vs. exact layouting
+
|}
  
interaction with rest of canvas
+
=== Transformations ===
 +
the leading question is whether or how these transformations affect the box, the text or both. a distinction has to be made between transformations that alter the shape of the text-box but leaving the glyph-shapes intact and transformation that affect the glyphs (e.g. 3D-perspective). Users need control over the scope of the transformation.
 +
==== resizing====
  
|-
+
resizing of text+box is on the one hand intuitive and context oriented, but on the other hand it violates full typographical control. Also when for example dragging the corner of a text box one does not grab the contained text, thus maybe does not expect it to change.
|'''creating'''
 
|click + enter text,
 
sets start point of baseline
 
  
resulting "shape" is always rectangular
+
==== rotation ====
| click + drag
+
for rotation the picture is a bit different: Here one would expect box and text to rotate simultaneously, e.g. the box is seen as the orientation for the text. The text is "aligned" to it.
 +
Yet (and especially for vector shapes) a rotation of either one, shape or text, is needed.
  
? convert rectangular vector shape + enter text?
 
| make vector or use existing
 
  
- wrap existing text to it
+
The new GIMP handles for resizing/transforming could be useful. (compare: [http://blog.mmiworks.net/2009/07/teaching-interaction-09.html student team 1] )
  
- enter text in shape with text tool
+
=== presets/styles ===
 +
a set of user-saved settings needs to be applicable (1) after creating a text-element and (2) to parts of a text-element. Both is not possible with current tool-presets. Whether text should reflect later changes in the according style is subject to discussion, but probably out of GIMP's focus.
  
|-
+
=== control/menu behavior ===
|'''modyfying'''
+
 
|resize not needed (if so -> becomes fixed shape)
+
==== editor ====
 +
The editor gives one-click access to a plain view of the text. All layouting apart from line-breaks and justification (both depending on the size of the text-element) needs to be visible.
 +
 
 +
Any intermediate abstraction from the image (e.g. turning the background off, but keeping the abstract shape of the text element) can be realized by the user via the layers dialog.
 +
 +
User can always switch between text-editor and canvas editing and changes made in the editor need to be displayed live on the canvas.
 +
Also the editor is the place where users shouldn't miss a single bit of text-functionality.
  
in-text layouting might modify shape
+
==== Toolbox, Editor and HUD ====
  
''rotate''
+
Current status:
*text only (changes box anyways)
+
The toolbox settings do not consider a selection made. This makes sense in the logic of treating the text-element as a whole but easily gets in the way of formatting. Also the HUD (for applying changes to selected text only) does not contain all options.
  
move
 
  
stroke/fill
+
Analysis of the three editing modes:
  
option to make fixed
+
{| border="1" cellpadding="5" cellspacing="0"
 +
!
 +
!Toolbox
 +
!HUD
 +
!Editor
 +
|-
 +
|purpose
 +
|main place for tool settings
  
| resize box (alters line breaks)
+
on canvas work without getting in the way
  
''rotate''
+
|quick access
*text only
 
*shape only
 
*text + shape
 
move
 
  
stroke/fill
+
undisturbed workflow
  
conversion to dynamic shape
+
experimenting
  
convert to complex shape
+
|plain view
  
| resize box (alters line breaks)
+
undisturbed by canvas
  
node manipulation (alters line breaks)
+
proximity of text to options
  
''rotate''
+
|-
*text only
+
|scope
*shape only
+
|full functionality
*text + shape
 
  
move
+
| restricted to basics
  
stroke/fill
 
  
conversion to dynamic shape (e.g. unbind from vector)
 
  
not possible to make basic shape
+
| full functionality
 +
|-
 +
|implementation
 +
|lack of space
  
|}
+
grouping of features (e.g. justification type).
 +
*The button can present the current state.
 +
|can disturb the view:
 +
* trigger on/off
 +
*appear on mouseover
 +
*opacity of about 50%
 +
 
 +
affects space for transformations
 +
 
 +
|quick switch via a button/shortcut
 +
 
 +
displays only in-text-layouting. shapes are not visible
  
==== order of conversions between shape types ====
+
live update of changes on the canvas
conversions are possible in this direction: click'n type -> basic shape -> complex shape
 
  
This reflects the degree in which the three modes place value on the shape.
+
ordering of functionality reflects the toolbox
  
==== specific text-shape objects for complex shapes? ====
+
enough space, no grouping necessary
For complex shapes the question arises whether it is the original vector object that contains the text, or if a copy of it as an specific text-shape is better suited.
 
pro original vector:
 
* unified approach
 
* no doubling of tools
 
* creating + later modyfing are the same
 
* changing vector means changing text shape. This is especially important, as this starting point implies a close binding of text to the canvas setting.
 
* if users want to losen this binding, a simple copy of the original vector is easily created
 
  
pro specific text-shape
+
|}
* indenpendence of vector
 
* possibility of adding text-specific controls
 
  
 +
=== misc ===
  
the former seems to better reflect the assumptions of this starting point
+
OpenType features are plentisome: Cannot be present on first level menu (maybe it suffices to have them in the menubar). However, they need to be accessible in a checkbox-manner to allow for quick switching on/off of multiple OT features.
  
==== container for complex shapes? ====
+
A simple glyph palette should provide manual access to all a font has to offer
  
a rectangular container around complex shapes provides advantages
 
* specification of left and right
 
* corners are nice places for on canvas controls
 
* provides a good way of keeping original vectors as shapes while still providing text-specific controls to it.
 
  
==== resize- or general transformation-behavior ====
+
* bold/italics could be named "manual bold/italics" and always do this. Professionals know about the possible existence of sub-fonts.
the leading question is whether these transformations affect the box, the text, or both?
 
  
resizing of text+box is on the one hand intuitive and context oriented, but on the other hand it violates full typographical control. Also when dragging the corner of a text box one does not grab the contained text, thus maybe does not expect it to change.
+
* stroke text or basic effect like drop-shadows should be shared with the new vector-tool. Text is nothing else than vectors.
  
for rotation the picture is a bit different: Here ob would expect box and text to rotate simultaneously.
+
==== font family and variant selection ====
  
This ambivalence can be solved, when the box is seen as the orientation for the text. The text is "aligned" to it. Therefore it might very well lead to a rotation of the text.
+
''Alternative:''
 +
two-step selection with variant as a sub-menu
 +
* + only one selector needs less menu space
 +
* + Good overview of families
 +
* + browsing feels quick
 +
* + one click selection
 +
* - user don't see what variants exist (Mouseover helps)
 +
* - difficult to handle
  
 +
==== effects/transformation and boundaries ====
 +
Current situation:
 +
when transforming text it loses its text-property but is nevertheless still limited to the size of the original text, which was used to layout the text (as a layer boundary) (the purpose for limiting the text area may be very different from the one for limiting a layer to a certain size)
  
Proposed solution for resizing: When using the external transformation tools, all that is in the selection should be affected. No distinction between box and contained text is made. However, when dragging a resize handle of the text box itself, it is clear that one is modyfiyng the container. Therefore in this case the text size stays unaffected.
+
In the future this issue will gain further importance by text being always editable (and therefore layouted by the text-engine).
 +
A transformation of glyphs or stroking them alters the visual size of the text. Line-breaks and wrapping (also in advanced text-element shapes) are calculated based on the dimensions of the glyph.
  
 
== scope of text-tool ==
 
== scope of text-tool ==
 
'''IN'''
 
'''IN'''
  
* typography aka in-text-layouting
+
* typography or more broadly: in-text-layouting
 
** character and paragraph level
 
** character and paragraph level
 
** preset functionality and behavior
 
** preset functionality and behavior
Line 523: Line 786:
 
*** need to be turned on and off quickly
 
*** need to be turned on and off quickly
 
*** have no need for most of the formatting options
 
*** have no need for most of the formatting options
*** searchable?
+
*** could profit from being searchable
 +
** very close to meta-information, which is out of the vision for text in GIMP
 
** = are better managed by its own system
 
** = are better managed by its own system
  
Line 531: Line 795:
 
*** …overloads the text tool
 
*** …overloads the text tool
 
*** …uses space and control used for text-specific work
 
*** …uses space and control used for text-specific work
** with GEGL a "link" between text-object and the shape should do the job
+
** a link between text and the shape should do the job
 
** = should be done in vector tool: unified approach
 
** = should be done in vector tool: unified approach
  
 
*text effects
 
*text effects
 
** drop shadow etc. are not unique to text
 
** drop shadow etc. are not unique to text
** useful for different sorts of objects (vectors)
+
** useful for different sorts of objects (e.g. any vector)
 
** workflow is "select object" - "apply effect", no matter if it is special to text or a global effect
 
** workflow is "select object" - "apply effect", no matter if it is special to text or a global effect
 
** = unified approach suits it better
 
** = unified approach suits it better

Revision as of 08:32, 9 September 2021

Contents

Introduction

Going beyond just looking at the Text tool, this project is about the complete text handling in GIMP. Examples of what this project addresses are: typographical control to the highest degree; wrapping to paths; arbitrary vector shapes for text boxes; placement and stacking order of multiple text boxes within a layer.

Vision

To guide all of the design work of this project, a vision was formulated for it. We combined GIMP’s product vision with insight into the activity and needs of core GIMP users where it comes to text, and added into the mix GIMP’s roadmap (i.e. GEGL). Boiled down to the essence, the vision is as follows:

  • Text in GIMP is always part of the composition—unless it is an annotation
  • The canvas is not a page; there is no such thing as paging in GIMP
  • Text in GIMP is both for reading and used as graphical shapes; meta data in text—mark-up, semantics—are not supported

GIMP users get:

  • Minute control over typography and the layout of text on the canvas
  • internationalisation of text handling, for all locales supported by unicode
  • text remains editable forever
  • super-fast workflow, when they are experienced

Functionality

Field survey

In order to compile a comprehensive list of what future text-handling in GIMP should include, we did a survey of other software packages in the field of GIMP.

Text in InDesign

Text in Scribus

Text in Photoshop

Text in Inkscape

Additionally a review of current text-functionality in GIMP, its technical background as well as capabilities of current or future libraries has been done.

Updated Text Functionality in Gimp 2.7.4

Processing of Text Input in Gimp

Pango features

Harfbuzz

note: just about all traits and transformations described below that can be applied to text, can be applied to:

  • a point in the text
  • a span
  • a paragraph
  • the whole text instance
  • several instances of texts

Internationalisation

  • multiple writing systems in the same text-box

Annotations

  • add, edit and delete annotations
  • show/hide
  • relate annotation to canvas
  • file-wide search of annotation text

Text box

  • add and delete text boxes
  • set position, size and stacking order
  • cut, copy + paste of boxes
  • wrap text to box or dynamic text box
  • text overflow from box to box

Text box geometry

  • text boxes of any shape
  • text (baseline, top of caps) along path
  • alignment axis (left, right , centre) along path
  • box geometry transformations

Text

  • add and delete characters
  • full support for all characters covered by Unicode
  • insert and overwrite
  • cut, copy + paste
  • mangage line-breaks, paragraphs, etc.
  • transformations
    • to upper, to lower, capitalise
    • rotate
  • execute spell check
    • select language (…-100s)
  • search + replace, for this text, whole file + all open files
  • rendering glyphs: fill, stroke and line style; see work on vector tool

Rulers

Typography

  • presets can be added, edited, deleted and applied
  • manual access to all characters of a font: Glyph palette

Character level

  • set font family (…-100s)
  • set font variant (1-~20)
  • set size(values between 1-infinite)
  • set color
  • set hinting (2-5)
  • set kerning (value)
  • set tracking (value)
  • toggle faux bold+italics (0,1)(0,1)
  • toggle underline (0,1) + (options)
  • toggle through-line (0,1) + (options)
  • set baseline shift (value)

see the list of non script-specific OpenType features (68) examples:

  • historical ligatures: Some ligatures were in common use in the past, but appear anachronistic today. Some fonts include the historical forms as alternates, so they can be used for a 'period' effect.
  • superscript: use to automatically access the superior figures (more legible than scaled figures)

+ there are the script-specific features (also ~68)

  • set glyph scaling (vertical and horizontal) (2 values)

line and paragraph level

  • set margins (4 values)
  • set leading (value)
  • set indent (value)
  • choose alignment (justification (1 [?+4 for last line]), flush (2), center)
  • set inter-paragraph spacing (value)
  • choose text-flow (all 4 directions)

User scenarios

Photographer (Annotations)

(see scenario 1a)

  • open file
  • apply changes
  • add text information to image
    • no effects, basic font+style+size
  • place text closer to part of image the note is about
  • on/off for annotations when wanting to work undisturbed

Creating Original Art

text as graphics

  • [no-text work]
  • freely define text-box-shape
  • enter text
  • experiment with font-family/variant/size/color
  • apply effects on all text elements
  • apply overall effect (let text "interact" with other parts of the composition)
  • transformation of text(-box) for perspective, 3D, paths.
  • fine-tune text, making use of advanced typography and optional manual replacements
  • apply more effects/brushwork/…
  • change wording

text as information

  • create several text-boxes (e.g. info)
    • define overflow direction
  • enter text / paste text (formatted or plain)
  • work on typography
    • basic settings font family + variant + size + color
    • set paragraph or text-box layouting (e.g. alignment, justification, writing direction, hyphenation)
    • fine-tune text, making use of advanced typography/OpenType and optional manual replacements
  • move, resize, reshape, reorder boxes
  • save/export/print
  • return later - load file
  • change wording/correct text
    • maybe change font (other computer)
    • adjust typography
  • save/export/print

Icon Design

  • Open/hot link to vector image
  • Polish & refine the icon
  • add very small amount of text
    • manually pick a glyph
  • deform text (vector-based)
  • apply pixel-based effects
  • Review icon & make changes to vector image (& edit text in GIMP). Go back to the 2nd bullet, and repeat.
  • Save Icon

Web Images - Production

text use mostly in buttons etc.

  • insert text, where it needs to be graphically altered or integrated with the pixel level
  • replacement of text for production of multiple instances of the same design element
  • Make sets of image elements, see how they work together
    • see how use of text in different parts works together - adjust typography accordingly
  • Export parts in optimised web format

Evaluation

evaluated tools: GIMP (2.7.4), Inkscape, Scribus, InDesign, Photoshop

Photographer (Annotations)

text placement

one-click or define frame first (Gimp, Photoshop, Inkscape)

  • + gives most flexibility
  • + is easy to handle with one button
  • + feels real. You can grab a pen, place it and start writing right away

the mouse pointer is important. A Cursor I is not useful for creating a box and a + is not handy to start typing right away.

Mandatory fixed-box definition (Indesign, Scribus)

  • - may disturb the work-flow in a graphic tool but is appropriate for desktop publishing. In a graphic-context users should decide whether they want to break lines manually with the Enter-Button or by pre-defining a vertical border (e.g. the right and lower side of the box).

adding second element

click anywhere outside the text-box

  • + fast
  • + text-tool does what can be expected

confirm editing, then click outside the text-box (Photoshop)

  • + (see moving the box)
  • - gets in the way of quickly creating multiple boxes

basic font-style-size settings

select tool preset and apply it:

  • + quick
  • + anytime, because applying to whole text is enough
  • - tussle between using a general default for every box, having to pick one every time, or taking the last-used settings

resize

grab corners/sides of box and drag (GIMP, PS, Inkscape)

  • + quick, inside the tool

select transformation tool (Scribus)

  • - leaving text-work for minor adjustments

move

select move tool, then click

  • - disturbs workflow

select transformation tools, then click on text (Inkscape)

  • + all transformations in one place
  • - disturbs workflow

click and drag anywhere on the canvas, outside the text box (PS)

  • + fast, basic transformations on hand

switch annotations on/off

not possible in GIMP

Creating Original Art

text along path and custom text-box shape

path and text, then "merge. No text-box shape transforms (GIMP)

  • + can be done anytime
  • - text DOES NOT stay editable
  • - order things are done is mandatory: both, text and path have to exist in the first place
  • - also the path has to be selected in the path dialog, though the text is selected on the canvas, to attach one to the other.

first path, then text (Photoshop)

  • + It feels intuitive to move text tool on or inside a path and thereby "attaching" the text to it
  • + one tool to place regular text, attach it to a path or wrap it to a shape
  • + stays editable
  • + warping presets can be applied anytime
  • + nice to define either baseline or box shape in the same way using the path tool
  • + option of flipping text to other side of path/use ascender instead of descender to aline with path
  • - no direct way to later make an already written (and formatted) text go along a path

first path then text with special text along path tool (InDesign)

  • + stays editable
  • + text boxes can be directly transformed by grabbing a corner, etc.
  • - no direct way to later make an already written (and formatted) text go along a path
  • - special tool can only be used on path anyway. PS gives a better solution

path and text, then "merge". Text-box form is part of text properties (Scribus)

  • + can be done anytime
  • + text box shape as part of text properties is really effective
  • + separation of path and text-box form makes sense. However, when making text go along a path the path becomes the form of the text box.
  • - order things are done is mandatory: both, text and path/shape have to exist in the first place

path/shape and text, then "merge" (Inkscape)

  • + can be done anytime
  • + nice universal solution, only the last step ("along path" or "flow into form") differs
  • + text and path always editable
  • - order things are done is mandatory: both, text and path/shape have to exist in the first place

font family and style/variant selection

all-in-one (Inkscape, Gimp)

  • + only one selector needs less menu space
  • + immediate overview of all available font options
  • + 1 click selection
  • - list grows in length by a considerable amount
  • - hard to tell sub-fonts of the same family and different fonts apart

two separate selectors (Photoshop, InDesign, Scribus)

  • + Good overview of families
  • + good for work in one family
  • - users don't see what variants exist, but have to actually select a font to get this information. This takes time when browsing through (Open Type) fonts.


find a middle way

Additional remarks

  • A preview in the font selection tool comes handy and saves time as users can omit unnecessary tryout clicks.
  • An icon showing the font's type (TTF, OT, etc) helps (also visually) when browsing the font list.

native font variant versus variant toggling (?faux)

GIMP At current state GIMP does not behave in any of the ways mentioned above. Buttons for faux (presumably) b./i. exist. The display does not indicate a switch to an existent pre-defined sub-font. Also, the toggle buttons do not have any effect when a respective sub-font hast been chosen. (no double bold). A decision should be taken about the way this works and feedback needs to be give to the user.

no faux bold/italics, only font-integrated options available (Scribus)


faux bold/italics toggles

if implemented an automatic switch to pre-designed (Inkscape) applies a change not in the place where user sets it. At least an indicator should be present.

An explicit faux b./i. switch (Photoshop) seems more intuitive and gives more control to the user (double bold).

transformations of text(-box) (e.g. for perspective)

select desired transformation tool, apply

  • + universal
  • - only applicable to text. box is not an object itself
  • - text is non editable afterwards (only if transformation is undone)

Photoshop

  • simple shape:
    • scaling changes box
    • rotating changes text+box
  • + stays editable
  • complex shape:
    • original shape is copied to a text shape
    • transformations always effect text+box
  • - easy to lose the ability to edit text

Inkscape

  • scaling changes text (and box)
  • rotating changes only text
  • other transformations change text+box

Advanced Typography

Photoshop (and InDesign):

The most basic settings are in a toolbar. For quick typography this does the job. The toolbar also includes a button to open the typography window.

The typography window with it's two tabs and an included menu contains all options available. The first tab shows all settings on a character level, the second one on the paragraph level. The menu hosts all the settings plus a few extra options, like a reset.

Character tab: font family and variant come first. The next section contains metrical adjustmens of font size, leading (line-spacing), tracking (letter-spacing) and kerning. Whereas the former three work on any selection, kerning needs to be adjusted for individual pairs of letters. Therefore the cursor has to be placed between the two letters, to make the the kerning setting accessible.

  • - confusing that entry boxes show unit ( Pt ) but this is not changeable.

The next section allows for vertical and horizontal glyph scaling, plus setting a baseline offset and selecting a text color.

Next comes a row of buttons for toggling faux bold, italics, capitals, small capitals, superscript, subscript, underline and through-line. Last comes a language selector and a drop-down menu to choose hinting.

Paragraph tab: All settings affect the whole paragraph.

First comes a line of alignment buttons. Justification options are greyed out, when text is in a dynamic shape.

The next section allows for setting a first line indent, as well as general left or right indents and spacing before and after the paragraph.


Overall:

  • + the tabs are a functional way of using rare space
  • + tabs provide better overview through structurization
  • + the grouping is mostly understandable


Inkscape:

Inkscape offers a toolbar and an extra window for text-settings.

Extra Window

Editing tab: Plain text

Font tab: Select font family, variant and size. Also alignment, text-flow and line-spacing. A preview is in the bottom line.

Toolbar

font family, no variant (!), size, bold and italics, alignment, super- and subscript. Leading, tracking, spacing between words, kerning, vertical shift, glyph rotation and text-flow.


  • + clear icons
  • + good control for metric settings
  • + glyph palette
  • - distribution of settings


OpenType is only available in Photoshop (basic functionality) and InDesign (extensive functionality). All Options are accessed via a menu in the typography window. They are presented as as on/off switches.

  • + too much for direct access via toolbox
  • - when wanting to select more than one, users have to open the menu again and again.

Checkboxes seem to solve the above issue

tool presets/styles

tool presets (GIMP, Photoshop)

  • + give users the option to customize and build a library of often used settings
  • + integrate well with the rest of the program. Universal solution
  • - users cannot apply them to already existing text, eliminating a big number of possible use cases. In GIMP one can apply them to a selected text, but only to the whole box. (Also, the behavior is not always predictable: Switching between tool presets changes the text orientation. Bug?)

text styles (Scribus, InDesign)

  • + give users the option to customize and build a library of often used settings
  • + always applicable, making it possible to write first and format later with some predefined styles. This gives more freedom.
  • + can be put next to the text settings, giving quick access and making it easy to see they take effect
  • - need toolbox space (toolbox, because they only make sense when quickly accessible)

Inkscape does not save any user settings in the text tool besides setting a default.

Icon Design

glyph palette

not available (GIMP, Photoshop)

  • - A switch to other tools takes time to open the tool and searching the desired font again

Web Images Production

settings not applicable to several texts (unless style-markup exists)


General

placement of tool options

tool options (on side)/ toolbar (on top)

  • + more (all) options on screen
  • + no extra dialog
  • + users can do many changes with one-click
  • - uses space
  • - the options need to be divided, some features (e.g. OpenType features, advanced functions) are put in a menu


extra window (text editor, options)

  • + all of the functionality in one place (at least that's possible)
  • + good overview
  • + focus on textwork makes it especially fast to work with
  • + comes handy in cases where effects/layouting disturb editing.
  • - Having some of the formatting options only available in external dialog (Inkscape) is bad for the workflow.
  • - Changes are not in the context of the work (no live update on canvas)

GIMP currently uses a combination of toolbox, extra window and heads-up-display

  • + separable radius of effect: toolbox for whole text-box, hud for selected text.
  • - above also presents difficulties:
  • - in none of the three, ALL options be found
  • - a checkbox does not seem the right way to start the text-editor

Analysis

In GIMP text handling there are

  • text, as text itself,
  • vector object container and
  • paths, which modify text.

Text (down to glyph level), vector container and path must all be able to be manipulated individually.

Text

  • Text, as text itself
    • it has no container
    • but a position
    • and typographical parameters

Typography Overview

Typography overview.jpg

(missing: inter-paragraph spacing, text-flow)

These are all properties that are part of the text itself and do not need an additional object (e.g. a container) to take effect.

The followig are text properties but need an external object to take effect:

  • margins (debatable whether left and top margin have an effect in text without box. They could shift it according to the original coordinate.)
  • justification

Vector object container

  • Vector object containers

The text vector container spans from:

    • a simple text container
    • to a complex geometric vector form.
    • the text is contained
    • the text layout is modified by the vector shape
    • it provides a reference for typographic features that depend on it. (margins, justification)

The actual space for holding text is the inside of the vector container minus the respective margins.

  • Margins are a property of the respective paragraph.
  • They can differ between different paragraphs.
  • They are not a property of the vector object.

Glyph placement

principle: Text in vector object means nothing is outside! e.g.:A glyph can only be placed, when around it, there is enough space for all margins.

? What is first set: the first baseline or the first glyph?

A glyph is moved to the next line, when

  • placement of the glyph on the current line

leads to

  • its body dimensions (or outline/blackbox) plus the margins

being on the edge or outside of

  • the vector object container


  • Text runs endlessly
  • The placement described above refers to visibility
  • After the last possible (e.g. bottom-right) glyph has been placed, text can still be entered and is stored as part of the text object.
  • It can become visible through
    • increase of vector object size
    • decrease of margins
    • decrease of font-size or general in-text spacing
    • definition of a next vector object container for text overflow
    • etc.

specific text-shape objects for complex shapes?

For complex shapes the question arises whether it is the original vector object that contains the text, or if a copy of it as an specific text-shape is better suited.

pro original vector:

  • unified approach
  • no doubling of tools
  • creating + later modyfing are the same
  • changing vector means changing text shape. This is especially important, as this starting point implies a close binding of text to the canvas setting.
  • if users want to losen this binding, a simple copy of the original vector is easily created

pro specific text-shape

  • independence of vector
  • possibility of adding text-specific controls

container for complex shapes?

a rectangular container around complex shapes provides advantages

  • specification of left and right
  • provides a good way of keeping original vectors as shapes while still providing text-specific controls to it thereby adressing some of the points above.

holes/wrapping around vectors

text can not only be inside a vector shape but also around a vector shape.

  • property of the vector object
  • linked to as many instances of text as wanted
  • also vector shapes serving as text containers can have this property towards other text instances
  • Users need to be able to explicitly control which text instances the vector object influences.

Paths

  • Path modify text, or more specifically
    • the baseline(s)
    • the alignment-axis
    • if the text is contained in a vector shape the path modifies the text- which is contained by the vector object.


Text along path

  • correct name: baseline along path
  • It dissolves the straightness of baselines

Text exmp t-a.jpg

The left an right side of the text are boundaries.

Options: (options in brackets, defaults in italics)

  • Flip side (left side/right side)
  • set range on path (whole path)
  • toggle multiple lines? (on/off)
  • set reference line (descender height, baseline, median, cap height, ascender height)

where does new lines get added? Moving up is not in line with the coordinate thing of sole text

Text from path

  • correct name: alignment axis along path
  • It dissolves the parallelity of baselines.

Text exmp t-f.jpg


Options: (options in brackets, defaults in italics)

  • flip side(left/right side) (e.g. flip direction)
  • set range on path (whole path)
  •  ?line overlap (on/off)
    • happens with small leading values too

Combinations

Positioning

as positions on the canvas of text elements and properties are likely to conflict the hierarchy is as follows:

  • the container
  • the path
  • the text itself

Position properties are not lost when not taking effect in hierarchy. When connections between objects is cut, the one lower in hierarchy returns to its own position

Overview

Sole text Text in vector object container
no path Text exmp t-n.jpg
  • positioning by text obejct (coordinate is property)
  • Only two (left and top) boundaries
  • alignment and justification properties do not take effect
  • margin can only take effect on two boundaries
Text exmp rv-n.jpg
  • positioning by vector object
  • all four boundaries available
  • = alignment, justification, margins, all there
along path


Text exmp t-a.jpg
  • positioning by path
  • provides third (second in text flow) boundary = end of path!
  • Left/right alignment available
Text exmp rv-a.jpg
  • positioning by vector object
From path Text exmp t-f.jpg
  • positioning by path
Text exmp rv-f.jpg
  • positioning by vector object


from+along path
  • options and defaults are defined by individual path modifiers
File:Example.jpg
  • positioning by from path
File:Example.jpg
  • positioning by vector object

Transformations

the leading question is whether or how these transformations affect the box, the text or both. a distinction has to be made between transformations that alter the shape of the text-box but leaving the glyph-shapes intact and transformation that affect the glyphs (e.g. 3D-perspective). Users need control over the scope of the transformation.

resizing

resizing of text+box is on the one hand intuitive and context oriented, but on the other hand it violates full typographical control. Also when for example dragging the corner of a text box one does not grab the contained text, thus maybe does not expect it to change.

rotation

for rotation the picture is a bit different: Here one would expect box and text to rotate simultaneously, e.g. the box is seen as the orientation for the text. The text is "aligned" to it. Yet (and especially for vector shapes) a rotation of either one, shape or text, is needed.


The new GIMP handles for resizing/transforming could be useful. (compare: student team 1 )

presets/styles

a set of user-saved settings needs to be applicable (1) after creating a text-element and (2) to parts of a text-element. Both is not possible with current tool-presets. Whether text should reflect later changes in the according style is subject to discussion, but probably out of GIMP's focus.

control/menu behavior

editor

The editor gives one-click access to a plain view of the text. All layouting apart from line-breaks and justification (both depending on the size of the text-element) needs to be visible.

Any intermediate abstraction from the image (e.g. turning the background off, but keeping the abstract shape of the text element) can be realized by the user via the layers dialog.

User can always switch between text-editor and canvas editing and changes made in the editor need to be displayed live on the canvas. Also the editor is the place where users shouldn't miss a single bit of text-functionality.

Toolbox, Editor and HUD

Current status: The toolbox settings do not consider a selection made. This makes sense in the logic of treating the text-element as a whole but easily gets in the way of formatting. Also the HUD (for applying changes to selected text only) does not contain all options.


Analysis of the three editing modes:

Toolbox HUD Editor
purpose main place for tool settings

on canvas work without getting in the way

quick access

undisturbed workflow

experimenting

plain view

undisturbed by canvas

proximity of text to options

scope full functionality restricted to basics


full functionality
implementation lack of space

grouping of features (e.g. justification type).

  • The button can present the current state.
can disturb the view:
  • trigger on/off
  • appear on mouseover
  • opacity of about 50%

affects space for transformations

quick switch via a button/shortcut

displays only in-text-layouting. shapes are not visible

live update of changes on the canvas

ordering of functionality reflects the toolbox

enough space, no grouping necessary

misc

OpenType features are plentisome: Cannot be present on first level menu (maybe it suffices to have them in the menubar). However, they need to be accessible in a checkbox-manner to allow for quick switching on/off of multiple OT features.

A simple glyph palette should provide manual access to all a font has to offer


  • bold/italics could be named "manual bold/italics" and always do this. Professionals know about the possible existence of sub-fonts.
  • stroke text or basic effect like drop-shadows should be shared with the new vector-tool. Text is nothing else than vectors.

font family and variant selection

Alternative: two-step selection with variant as a sub-menu

  • + only one selector needs less menu space
  • + Good overview of families
  • + browsing feels quick
  • + one click selection
  • - user don't see what variants exist (Mouseover helps)
  • - difficult to handle

effects/transformation and boundaries

Current situation: when transforming text it loses its text-property but is nevertheless still limited to the size of the original text, which was used to layout the text (as a layer boundary) (the purpose for limiting the text area may be very different from the one for limiting a layer to a certain size)

In the future this issue will gain further importance by text being always editable (and therefore layouted by the text-engine). A transformation of glyphs or stroking them alters the visual size of the text. Line-breaks and wrapping (also in advanced text-element shapes) are calculated based on the dimensions of the glyph.

scope of text-tool

IN

  • typography or more broadly: in-text-layouting
    • character and paragraph level
    • preset functionality and behavior
    • OpenType implementation may need to be postponed
  • editing modes
    • editor, on canvas, HUD
    • level of abstraction
  • basic shape
    • non-shape, rectangle
    • creation
    • modification
  • text in 2D-space
    • needs logical specification
    • needs ui implementation, how to make the two tools work together
    • dependencies: vector tool, GEGL (for non-destructiveness)


OUT

  • annotations
    • differ in many dimensions to usual text:
      • need to be turned on and off quickly
      • have no need for most of the formatting options
      • could profit from being searchable
    • very close to meta-information, which is out of the vision for text in GIMP
    • = are better managed by its own system
  • complex shape/vector management
    • creation and modification of complex shapes and paths is exactly what the new vector tool is made for
    • doubling it in the text-tool…
      • …overloads the text tool
      • …uses space and control used for text-specific work
    • a link between text and the shape should do the job
    • = should be done in vector tool: unified approach
  • text effects
    • drop shadow etc. are not unique to text
    • useful for different sorts of objects (e.g. any vector)
    • workflow is "select object" - "apply effect", no matter if it is special to text or a global effect
    • = unified approach suits it better

Current state

see Work_in_progress#Text_in_GIMP for current state