Skip to content

Commit

Permalink
hack text layouting into text display method for standard Text
Browse files Browse the repository at this point in the history
needs my AbstractPlotting layout_text rework
  • Loading branch information
jkrumbiegel committed Mar 28, 2020
1 parent e9323bb commit 41fd246
Showing 1 changed file with 24 additions and 2 deletions.
26 changes: 24 additions & 2 deletions src/primitives.jl
Original file line number Diff line number Diff line change
Expand Up @@ -76,13 +76,35 @@ function draw(scene::Scene, plot::AbstractPlotting.Text)
@get_attribute(plot, (textsize, color, font, align, rotation, model))
txt = to_value(plot[1])
position = plot.attributes[:position][]

# hack layouting into the process here
if position isa Point
position, _ = AbstractPlotting.layout_text(
txt, position, textsize,
font, align, rotation, model
)
end

# hardcode this against abstractplotting madness
# all textsizes in the vector are different, one for each glyph, which
# has to do with the texture atlas
# 20 is just the default makielayout fontsize
textsize = 20f0

plotwindow_width = topparent(scene).px_area[].widths[1]

This comment has been minimized.

Copy link
@asinghvi17

asinghvi17 Mar 28, 2020

Member
    plotwindow_width = widths(pixelarea(root(scene)))[1]

Edit: this should be the working version:

    plotwindow_width = widths(pixelarea(root(scene))[])[1]

This comment has been minimized.

Copy link
@jkrumbiegel

jkrumbiegel Mar 28, 2020

Author Member

you should really check your suggestions first before you post them and I have to :) this does not work because pixelarea returns an observable

This comment has been minimized.

Copy link
@asinghvi17

asinghvi17 Mar 28, 2020

Member

Whoops, sorry about that! For some reason I thought that wouldn't return an observable.


N = length(txt)
broadcast_foreach(1:N, position, textsize, color, font, rotation) do i, p, ts, cc, f, r
pos = project_position(scene, p, model)
chup = r * Vec2f0(0, 1)
GR.setcharup(chup[1], chup[2])
GR.settextfontprec(233, 3)
GR.setcharheight(0.018) # ts ???

# helvetica in string mode seems to work relatively well for some reason
GR.settextfontprec(105, 0)
# GR.setcharheight(0.018) # ts ???

# convert textsize to plotwindow_width percentage
GR.setcharheight(textsize / plotwindow_width * 0.666) # why 2/3ds? window size seems always too large

This comment has been minimized.

Copy link
@asinghvi17

asinghvi17 Mar 28, 2020

Member

Possibly because the GR window does not respect the Scene's pixel area. @jheinen had a fix for this locally, I think...

GR.settextcolorind(Int(GR.inqcolorfromrgb(cc.r, cc.g, cc.b)))
GR.settransparency(cc.alpha)
GR.settextalign(1, 4)
Expand Down

4 comments on commit 41fd246

@jheinen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, it's all a big guessing game. I can only repeat: Either GR draws and positions the texts, or Makie. A hotchpotch makes no sense at all. Please regard this comment as constructive criticism.

@jkrumbiegel
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I personally think AbstractPlotting should position all the glyphs and the backend should draw them. That's what I'm doing in my edit and it seems to work well. The only thing is that I don't know how to have GR draw custom FreeType fonts. As far as I can see I can only choose from predefined choices using some integers. I remember you saying at vizcon that this could be possible soon, Josef?

@jheinen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But you only can position the glyphs if you have the exact geometry/kerning information. If Makie has this information and can use it for positioning and aligning texts in 2d and 3d, then why draw them (and send the coordinates to the backend).

Alternatively everything could be managed by the backends, but then, the backend need more abstract information, e.g.: Draw a text at postition (x, y) with character up-vector(s) (ux, uy) (and (vx, vy) in 3d space), size cs (in device independent coordinates), horizontal/vertical alignment ...

IMO positioning/alignment/rendering should be in one place. If on a higher level, you need geometry information about glyphs, you will have to inquire them from the backend. In case of GR, by using inquire text extent functions which will return a bounding box and a concatenation point.

@jkrumbiegel
Copy link
Member Author

@jkrumbiegel jkrumbiegel commented on 41fd246 Mar 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have glyph metrics through FreeType. The fonts that I usually use (Avenir, Helvetica Neue, SF Compact) seem to lack kerning information but positioning text via the metrics looks quite good to me. Certainly useable. I basically just want the backend to place the glyphs where I tell it to. If the backend deals with the layout, at least I need to be able to easily query the bounding box, even before the scene is drawn, because I need this information to compute the scene layout.

Please sign in to comment.