Is there a pushMatrix()/popMatrix() analog to this processing code that tries to assign custom attributes to text?
pushMatrix();
textAlign(CENTER);
fill(0, 255, 0);
text("Hello world.", 0, 0);
popMatrix();
This code does not work; the popMatrix() does not undo the attribute assignments. Any text typed after popMatrix() is still center-aligned and green.
Yes, there is, and it applies to all styles(fill(),stroke(),etc.) , not just text attributes: have a look at pushStyle()
From docs:
The pushStyle() function saves the current style settings and
popStyle() restores the prior settings. Note that these functions are
always used together. They allow you to change the style settings and
later return to what you had. When a new style is started with
pushStyle(), it builds on the current style information. The
pushStyle() and popStyle() functions can be embedded to provide more
control (see the second example above for a demonstration.)
The style information controlled by the following functions are
included in the style: fill(), stroke(), tint(), strokeWeight(),
strokeCap(), strokeJoin(), imageMode(), rectMode(), ellipseMode(),
shapeMode(), colorMode(), textAlign(), textFont(), textMode(),
textSize(), textLeading(), emissive(), specular(), shininess(),
ambient()
Related
I have noticed that a text in the rich edit control (only a single line) is not centered vertically. A space between a text and a top border edge is larger than a space between a text and a botttom border edge. It is especially visible when a rich edit control height is only a little bit bigger that a text height. PARAMFORMAT only allow to set a horizontal alignment. How to set a vertical alignment / top-bottom margins ?
Edit:
This way I get PARAMFORMAT2 structure:
PARAFORMAT2 pf;
ZeroMemory(&pf, sizeof(pf));
pf.cbSize = sizeof(pf);
SendMessage(hwndRichEdit1, EM_GETPARAFORMAT, 0, (LPARAM)&pf);
dySpaceBefore is already initially set to 0 and the effect you can see on the attached screenshot.
I use Visual Studio 2017, MSFTEDIT_CLASS is defined in Richedit.h as L"RICHEDIT50W"
If you're using a Rich Edit 2.0 control, you can use the PARAFORMAT2 structure, which has the option to set the space before the text.
You haven't added a language tag, but here's how you would do it in C (see also the documentation for EM_SETPARAFORMAT):
//...
PARAFORMAT2 pf2;
pf2.cbSize = sizeof(PARAFORMAT2);
pf2.dwMask = PFM_SPACEBEFORE; // Of course, you can OR in other bits/options to set!
pf2.dySpaceBefore = 0; // Will align to the top; use a small +ve value, if you prefer
SendMessage(hWndEdit, EM_SETPARAFORMAT, 0, (LPARAM)&pf2);
//...
To get vertically centred text is bit more work, as you will need to get the height of the text (using GetTextExtent) and the height of the control's client rectangle, then use a 'space before' value of (client_height - text_height)/2.
Feel free to ask for further clarification and/or explanation. (I may even be able to offer you code in another language.)
I can reproduce this issue like this snapshot shows:
There seems no feature supported for vertical alignment center. I've submit a feature request internally.
A workaround is using EM_SETRECT which can move up text area via limiting rectangle into which the control draws the text. The following snapshots show its effects:
Then you can use it to adjust the text to display it in center between top and bottom.
Code example:
HWND hwndEdit = CreateWindowEx(
0,
MSFTEDIT_CLASS,
TEXT("EDIT"),
WS_BORDER | WS_VISIBLE | WS_CHILD,
20,
20,
100,
32,
hWnd,
NULL,
hInst,
NULL);
RECT rect;
SendMessage(hwndEdit, EM_GETRECT, 0, (LPARAM)&rect);
rect.top -= 2;
rect.bottom -= 2;
SendMessage(hwndEdit, EM_SETRECT, 1, (LPARAM)&rect);
I have the following palettes, with various hue values, being applied to multiple themes in my material-theme.scss file:
$green: mat-palette($mat-green, A400);
$blue: mat-palette($mat-light-blue, A400);
$red: mat-palette($mat-red);
$red-warn: mat-palette($mat-red, A100);
In my material-styles.scss file, I have a mixin that is used to define styles based on the current theme:
#mixin style-theme($theme) {
$p: map-get($theme, primary);
$a: map-get($theme, accent);
$w: map-get($theme, warn);
$primary: mat-color($p);
$accent: mat-color($a);
$warn: mat-color($w);
$primary-contrast: mat-contrast($p, 500);
$accent-contrast: mat-contrast($a, 500);
$warn-contrast: mat-contrast($w, 500);
// Apply styling based on values above
}
Themes are created as follows:
.light-green {
$default-theme: mat-light-theme($green, $blue);
#include style-theme($default-theme);
#include angular-material-theme($default-theme);
}
Is it possible for me to get the contrast of the currently applied palette? As it is now, I am only able to hard-code the $hue value for the mat-contrast function.
StackBlitz Demo
There are six 'special' keys that are automatically added to a palette when you use mat-palette():
default
lighter
darker
default-contrast
lighter-contrast
darker-contrast
Each base palette contains all of the colors mapped to the keys 50, 100, ... 900, A100, A200, A400, A700. It also contains a sub-palette mapped to the key 'contrast' with a set of contrast colors mapped to the same keys. The colors assigned to the special keys correspond to the hue values passed in to mat-palette(), which default to 500, 100, and 700 respectively for default, lighter, and darker. The '*-contrast' mapped colors are pulled from the contrast sub-palette using the same hue value keys.
When you call mat-color() without a hue key it uses default as the key. But you could use any of the special keys so that you don't need to know which hue values are actually mapped to the special keys.
So for example, you could call mat-color($green, default-contrast) to get the proper contrast color for the default color in your green palette.
I was able to figure it out by inspecting the theming for MatToolbar.
You can get the contrast color value for a palette using the following:
$contrast: mat-color($palette, default-contrast);
See revised StackBlitz Demo
I'd like to use custom drawing within a Gtk::Layout. That is, I'm using the C++ bindings for Gtk3 (GTKmm 3.14.0), and I have embedded widgets placed on the "canvas", on top of my custom drawing. Basically this works just fine.
Now the problem is related to scrolling. Gtk::Layout can be placed into a Gtk::ScrolledWindow, and when the scrollable area is set to something larger than the visible allocation, scrollbars will show up. Unfortunately, those scrollbars influence only the placement of the embedded widgets, while my custom drawing remains at a fixed position within the window.
This means, both the Gtk::Allocation and the cairo context seem to be related to precisely the visible area, not to the extended virtual "canvas". I could work around that problem by accessing the adjustments from the scrollbars and then translate the cairo context accordingly...
My question is:
is this the proper way to handle such a scrollable drawing?
or is there some way to let the framework do this work for me?
Judging from the source code of gtk+3.0-3.14.5 (which is in Debian/Stable), the Gtk::Layout does nothing to adjust the drawing context. It just invokes the inherited draw() function from GtkWidget. On the other hand, Gtk::Layout is a full-blown container (it inherits from Gtk::Container), and it is scrollable, which together means that it handles gtk_layout_size_allocate() by passing a suitable allocation (screen area) to each of the embedded child widgets -- and in this respect it does handle the moving and clipping related to scrolling the virtual canvas (calls gdk_window_move_resize()).
Thus, if we want to combine the embedded child widgets with custom drawing, we need to bridge this discrepancy manually. This is quite easy actually: all we need to do is to look into the Gtk::Adjusments corresponding to the scrollbars. Because the value of these adjusments is precisely the upper left corner of the visible viewport. Now, if we want our custom drawing to use absolute canvas coordinates, we just have to translate() the given Cairo context. Beware: it is important to save() the state and to restore() it to pristine state when done, otherwise those translations will accumulate.
Here is some example code to demonstrate this custom drawing
we derive a custom container class called Canvas from Gtk::Layout
we override the on_draw() handler, because only there all size allocation to embedded child widgets have been processed
Layering: child widgets are always drawn in the order they have been added to the Gtk::Layout container. Any custom drawing done before invoking the inherited on_draw() function will be below those widgets; any drawing done afterwards will happen on top of them.
if necessary, we can use the foreach(callback) mechanism to visit all child widgets to find out their current position and extension
void
Canvas::determineExtension()
{
if (not recalcExtension_) return;
uint extH=20, extV=20;
Gtk::Container::ForeachSlot callback
= [&](Gtk::Widget& chld)
{
auto alloc = chld.get_allocation();
uint x = alloc.get_x();
uint y = alloc.get_y();
x += alloc.get_width();
y += alloc.get_height();
extH = max (extH, x);
extV = max (extV, y);
};
foreach(callback);
recalcExtension_ = false;
set_size (extH, extV); // define extension of the virtual canvas
}
bool
Canvas::on_draw(Cairo::RefPtr<Cairo::Context> const& cox)
{
if (shallDraw_)
{
uint extH, extV;
determineExtension();
get_size (extH, extV);
auto adjH = get_hadjustment();
auto adjV = get_vadjustment();
double offH = adjH->get_value();
double offV = adjV->get_value();
cox->save();
cox->translate(-offH, -offV);
// draw red diagonal line
cox->set_source_rgb(0.8, 0.0, 0.0);
cox->set_line_width (10.0);
cox->move_to(0, 0);
cox->line_to(extH, extV);
cox->stroke();
cox->restore();
// cause child widgets to be redrawn
bool event_is_handled = Gtk::Layout::on_draw(cox);
// any drawing which follows happens on top of child widgets...
cox->save();
cox->translate(-offH, -offV);
cox->set_source_rgb(0.2, 0.4, 0.9);
cox->set_line_width (2.0);
cox->rectangle(0,0, extH, extV);
cox->stroke();
cox->restore();
return event_is_handled;
}
else
return Gtk::Layout::on_draw(cox);
}
I am using C++11 with GNU tool chain with gtkmm3, on Ubuntu 12.04 LTS 32 bit.
I have been playing wtih some of the examples for gtkmm3 in Programming with gtkmm 3.
Based on 17.2.1.Example there, I inherited from Gtk::DrawingArea (MyDrawingArea here) and overrode the on_draw() event handler as follows:
MyDrawingArea.hpp
...
protected:
bool on_draw ( const Cairo::RefPtr<Cairo::Context>& cr ) override;
MyDrawingArea.cpp
bool MyDrawingArea::on_draw( const Cairo::RefPtr<Cairo::Context>& cr )
{
Gtk::Allocation allocation = get_allocation( );
const int width = allocation.get_width( );
const int height = allocation.get_height( );
int coord1{ height - 3 };
cr->set_line_width( 3.0 );
this->get_window( )->freeze_updates( );
cr->set_source_rgb( 0, 0.40, 0.60 );
cr->move_to( 0, coord1 );
cr->line_to( width, coord1 );
cr->stroke( );
cr->set_source_rgb( 1, 0.05, 1 );
cr->move_to( mXStart, coord1 );
cr->line_to( mXStart, mYAxis * 1.5 );
cr->show_text( to_string( mYAxis ) );
cr->stroke( );
mXStart += 5;
this->get_window( )->thaw_updates( );
return true;
}
My goal is to draw a simple bar graph based on a calculation I do in a little test application, the idea being that each time the on_draw() event is called, the next bar would be moved 5 units to the right on mXAxis and a vertical line would be drawn based on the new mYaxis value, which is computed based on the results of the new calculation.
When I want to repaint my graph and trigger the MyDrawingArea::on_draw() event, I call MyDrawingArea.show_all() from my application after the calculation has completed, and new x and y axes have been set.
However, this does not work as I expected: MyDrawingArea.show_all() invalidates the entire drawing window and draws from scratch: the new graph line appears in its proper place, but the previous ones are erased. I also tried MyDrawingArea.queue_draw(), which had the same effect. But I want to persist the previous graph results so I can get a profile of the calculation results, as I calculate with different values.
This implementation is also causing the bottom line on my graph (my x axis on the graph)- drawn by the first stroke() call in my code example, to be rendered anew on each call to on_draw() - although this should not be necassary since this line persists for the lifetime of MyDrawingArea - it should not be necessary to invalidate and then re-draw it on each new on_draw() event, as my code is currently doing, because I am haven't yet found a way to handle this.
I am very new to Cairo, so I'm sure I'm probably doing this completely wrong, but explicit, task-oriented documentation appears to be sparse - have not found anything that explains how to do this, although I'm sure it is quite simple.
What do I need to do to draw a new line on Gtk::DrawingArea, while persisting previous graph lines that have already been drawn on previous passes, and establish graphics elements that will persist for the lifetime of the Gtk::DrawingArea widget. Obviously using show_all() or queue_draw() and doing it all in the on_draw() event is not the way to go.
In general, you must draw the entire widget and Cairo will clip the drawing to the predefined dirty region. See also GTK reference manual for the "GtkWidget::draw" signal for performance tips:
The signal handler will get a cr with a clip region already set to the
widget's dirty region, i.e. to the area that needs repainting.
Complicated widgets that want to avoid redrawing themselves completely
can get the full extents of the clip region with
gdk_cairo_get_clip_rectangle(), or they can get a finer-grained
representation of the dirty region with
cairo_copy_clip_rectangle_list().
So you may be able to redraw only the region you want with gtk_widget_queue_draw_area().
I need to render fonts into a 3d game world, so I use the GetGlyphOutline outline function to get the glyph shapes to render into a texture. However, I want to be able to handle the case where characters are not present in the given font (as is often the case for asian other other international text). Windows text rendering will automatically substitute fonts which have the needed characters. But GetGlyphOutline will not. How can I detect this case, and get the outlines for the substituted glyphs? Mac OS X Core Text has a function to get a matching substitution font for a given font and a string - is there anything similar on windows?
Found out what I needed to know myself: The IMLangFontLink interface, especially the MapFont method contain the needed functionality to find out which substitution fonts should be used on windows.
I too have puzzled with GetGlyphOutline. I'm not sure if you were able to do the same, but I was able to get mixed-script text outlines by using TextOut() in combination with BeginPath(), EndPath() and GetPath().
For example, even with the Arial font, I am able to get the path of the Japanese text 「テスト」 (using C++, but can easily be done in C as well):
SelectObject(hdc, hArialFont);
BeginPath(hdc);
TextOut(hdc, 100, 100, L"\u30c6\u30b9\u30c8"); // auto font subbing
EndPath(hdc);
// get number of points in path
int pc = GetPath(hdc, NULL, NULL, 0);
if (pc > 0)
{
std::vector<POINT> points(pc);
std::vector<BYTE> types(pc); // PT_MOVETO, PT_LINETO, PT_BEZIERTO
GetPath(hdc, &points[0], &types[0], pc);
// it seems the first four points are the bounding rect
// subsequent points match up to their types
for (int i = 4; i < pc; i++)
{
if (types[i] == PT_LINETO)
LineTo(hdc, points[i].x, points[i].y); // etc
}
}