Implement a specimen view

[davelab6]

@guiguru has written 2 pages on the wiki detailing the design:

• https://github.com/metapolator/metapolator/wiki/elements-of-design#working-with-masters-and-glyphs-in-context
• https://github.com/metapolator/metapolator/wiki/working-UI-demo#specimen--glyph-editor-panel

To start, @graphicore had some good ideas about how a JS API could return <use> elements to use in this, explained in http://youtu.be/UJc6SLJ5ztk?t=2h25m37s to the end. This is now implemented.

Next tasks:

Medium priority

• [x] take out the line spacing control and hardwire the normal spacing formula specced here
• [x] implement the 3 glyph mixer algorythms

Low priority

• [x] find and fix a bug in the rubberband selecting a set of glyphs and then shift-clicking to subtract one or more moved to #481.
• [x] fix bug, when you shift click on a glyph, a new browser window opens, but should not
• [x] full line spacing (loose, normal, tight, custom) UI control moved to #480
• [x] implement absolute function to calculate the size rope input

[davelab6]

@jeroenbreen wrote,

• selecting a glyph in the specimen (highlights it) by a click on the glyph. This makes it also selected in the parameters panel (is this designed already?)

Questions about rules for this: • clicking glyph "A" will select the "A"s of every master selected or only the masters "A" (I assume last)? • is the selection bar applied to every A of the master? • having no glyphs selected (of a master) makes the master selected. So in the parameters panel, the master is top level, right?

• I can ignore point selecting right, since we are not working on a deeper level then glyphs for the demo?

• I am thinking about this one: "the good news is that only what is visible needs to update". It will take some time to make a system that's keep tracking of what is invisible && unrendered. How relevant/highly priority is this? (It's not an enormous job, just want to know the priority compared to the other tasks)

I think @graphicore has already taken care of this with the CPS engine caching system.

• making shift and command click work. Shift => make a set from clicked to last clicked. Right? Command=> toggle the clicked. Right • what is "rubber-banding to make selections" (you might clarify in dutch)?

RubberBand is a term used in Qt, its also called "marquee" selection in eg Adobe apps:

• making a progress bar (what is the width of this bar and the selecting bar. Is it the width of the glyph or are all bars equal)?

• is sort by paragraph still in scope or is a paragraph to big for the demo?

Sort by Paragraph seems essential to me - "preview your font on editable paragraphs in real-time [is] Most requested feature so far!" - https://twitter.com/prototypoApp/status/535480102059270144

• I'm not happy with the technical way I built the size-rope thing. It works, but just wanted to have it said. Maybe somewhere at the end of the priority list I can rewrite it.

I agree, currently it has some bugs; if you pull it to the right and then move it left and right, the size value increments even when moving left, which seems weird to me; and if I pull it to the left, at exactly the 9pm angle, nothing happens.

@davelab6 , to my understanding of the video reference you made, @graphicore will make the API so that when I ask for a set of glyphs of a certain master, he will provide me the corresponding

@graphicore please provide more details about what the API will be like to call and what it will return :)

I'm not familiar with <use> yet, but from quick reading, I understand we can use this to make copy's of a glyph right? Sounds really useful.

Yeah, the <use> svg element uses the c++ svg renderer's "symbols" implementation, so we don't have to deal with that ourselves. (I say "symbols" as in the terminology used by the first vector graphics editor - http://en.wikipedia.org/wiki/Sketchpad / http://worrydream.com/refs/Sutherland-Sketchpad.pdf :)

So before that (Lasse), I'm going to use - starting tomorrow (thursday) some fake svg-boxes to develop the selecting stuff etcetera.

Yes, I think a SVG with some glyph shapes in a <def> area with IDs related to mock CPS selectors would make sense.

[jeroenbreen]

I agree, currently it has some bugs; if you pull it to the right and then move it left and right, the size value increments even when moving left, which seems weird to me;

Yeah that was something I wasn't sure about how this was designed. But from my understanding, whenever you are in the NE area, the fontsize should grow @guiguru if you have pull out the rope at a certain length and stop at that length, will the fontsize keep growing over time? (so is time a factor? Now its not)

and if I pull it to the left, at exactly the 9pm angle, nothing happens.

That is how it is designed by Peter: NE is + SW is -. Or are your talking specifically and only about exactly 9 o'clock?

But my comment about rebuilding it, was more about the fact that it is too much built in jquery and I did some other goofy stuff.

[guiguru]

@jeroenbreen wrote,

• selecting a glyph in the specimen (highlights it) by a click on the glyph. This makes it also selected in the parameters panel

yes.

(is this designed already?)

the parameters panel itself still needs a (simplified for this UI demo) design from me.

Questions about rules for this: • clicking glyph "A" will select the "A"s of every master selected or only the masters "A" (I assume last)?

only the glyph A of that master.

• is the selection bar applied to every A of the master?

yes, as it shows in the spec.

• having no glyphs selected (of a master) makes the master selected. So in the parameters panel, the master is top level, right?

in that case all masters that are highlighted in the master list (top right of that view) are the ones that are selected for parameter view and modification. yes, we support two levels for now: Master and Glyph. As said in the hangout: to change all masters at once users multi-select all the masters in the master list.

• I can ignore point selecting right, since we are not working on a deeper level then glyphs for the demo?

yes, no stroke or point interaction.

• I am thinking about this one: "the good news is that only what is visible needs to update". It will take some time to make a system that's keep tracking of what is invisible && unrendered. How relevant/highly priority is this? (It's not an enormous job, just want to know the priority compared to the other tasks)

this is essential to get any kind of workable speed out of this demo. @graphicore always talks about getting the outline of single glyphs computed. he expects that modern machines (like his) will compute 20 glyphs per second, it can get only slower with the work the UI code has to do and on non-modern, or el-cheapo, machines. A master is 127–1000+ glyphs (for latin); if there are 7 visible glyphs of a master that get changed (the logical AND of visible & the selection) then that should take 350ms (on @graphicore’s machine) not (at least) 127×50ms= 6.35 seconds.

users will be the final arbiter of the trade-off between seeing a lot of glyphs at once and speed. they have to be rewarded with speed when they concentrate on a few glyphs.

ps: note also this rule: (adjustment) masters that are not selected in the (adjustment) masters list(s), but do have their view toggle (in the view column) set to true, cannot be sub-selected in the specimen; they are never the working context for parameter and skeleton work.

it makes them static (non-updatable) in the specimen.

• making shift and command click work. Shift => make a set from clicked to last clicked. Right? Command=> toggle the clicked. Right

I just checked with the Finder (icon grid view), which is our reference. It is different than list views, and simpler (hurray): Shift and Command/Ctrl (it is ctrl on windows and linux machines) do exactly the same thing: allowing multiple select by allowing by click to toggle the select state of glyph (in our case).

• what is "rubber-banding to make selections" (you might clarify in dutch)?

rubber-banding is dragging a rectangle marquee over the ~icons~ glyphs (rechthoek slepen), like the rectangle selection tool @davelab6 showed. see again the finder.

all glyph boxes (see spec) that overlap (even with just a single pixel) within the marquee are to be selected (the mouse-down deselects the previous selection); when Shift or Command/Ctrl is held before the mouse-down, the marquee toggles the select state of the overlapping glyph boxes (i.e. unselected -> selected and selected -> unselected). the moment of mouse-down is all that matters for ‘is Shift or Command/Ctrl down?’

• making a progress bar (what is the width of this bar and the selecting bar. Is it the width of the glyph or are all bars equal)?

the selection highlight and the updating highlight are the same thing, just a different colour. it is basically the bottom border of the glyph box, 4-pix thick. glyph box widths vary, of course, for proportional fonts.

• is sort by paragraph still in scope or is a paragraph to big for the demo? yes, very useful, I also say.

• I'm not happy with the technical way I built the size-rope thing. It works, but just wanted to have it said. Maybe somewhere at the end of the priority list I can rewrite it.

• I'm not happy with the technical way I built the size-rope thing. It works, but just wanted to have it said. Maybe somewhere at the end of the priority list I can rewrite it.

there is one huge bug (sorry, I have to say it like that): you are making the changes relative instead of absolute, during dragging of the control. let me explain with an example:

1. starting situation: not dragging; display size is 100pt;
2. started dragging, control offset (h, v) = (10, 20)—going north-east; display size is 130pt;
3. adjusting the dragging (user wants to reduce the increase), control offset = (5, 15); display size is 120pt;
4. user wants no change at all, control offset = (-8, 15)—going north-west; display size is 100pt;
5. decreasing, control offset = (-10, -20)—going south-west; display size is 70pt;
6. mouse up, release the control; display size is the last one shown: 70pt;

ah, and the control shape is a square diamond, that is not decoration: it identifies the type of control.

I will now see how I can merge these clarifications in the wiki.

[jeroenbreen]

A master is 127–1000+ glyphs (for latin); if there are 7 visible glyphs

Not sure if we are talking about the same 'visible'. What I mean is - see screenshot: "The quick brown fox jumps" is visible, "over the" is half visible (ergo visible) and "lazy dog" is behind the scroll, so invisible (at this time).

[guiguru]

Not sure if we are talking about the same 'visible'. What I mean is - see screenshot: "The quick brown fox jumps" is visible, "over the" is half visible (ergo visible)

I agree

and "lazy dog" is behind the scroll, so invisible (at this time).

OK, I can appreciate now how tricky, subtle, and a pain in the neck to implement this is.

as guidance I can say:

1. the fact that a glyph is not within the viewport should give us an apparent speed benefit;
2. when the view is scrolled—and the view can be 10 times longer than the one shown here—the glyphs that become visible should be up-to-date.

it looks to me that that best strategy is to—

1. update all the glyphs in the specimen, when a parameter or metapolation is changed for them, but
   • priority 1: update what is inside the viewport first, in reading direction;
   • priority 2: update what is outside the viewport, in reading direction.

[jeroenbreen]

Well it's not that big of a pain, but just good to know whe are talking about the same now. I just have to build a sort of watch function, registering the size of the div and calculating glyph by glyph whether it's within it or not. And re-watching it after a scroll.

Maybe I am just asking for the priority of this. Because if you are scrolled at the top of the div (which will be most logic user scenario I guess), then not having such a watcher already satisfies your ordered list (1 update in viewport first, 2 update outside viewport). Your list is only relevant when user is not scrolled at the top.

[guiguru]

Well it's not that big of a pain,

OK, that is good news.

but just good to know whe are talking about the same now.

good to bring it up, because you may have noticed that I had not thought about it. it helped me to get clear how to achieve our UI goals.

Maybe I am just asking for the priority of this. Because if you are scrolled at the top of the div (which will be most logic user scenario I guess), then not having such a watcher already satisfies your ordered list (1 update in viewport first, 2 update outside viewport). Your list is only relevant when user is not scrolled at the top.

I am not going to prioritise the top of the specimen when it is long enough to scroll. I would say you use this info (specimen does not scroll, or scrolls-but-at-the-top) to simplify your watch function (use).

for me it is first priority that the updating behaviour of the specimen (for both parameters and metapolation) works, including the updating highlighting. you can see that in the design it is all quite tightly integrated: filtering, viewing, selection, updating.

[graphicore]

I think @graphicore has already taken care of this with the CPS engine caching system.

Yes, but the API that reneders the glyphs for the ui will still have to know wich glyphs to render and which not.

@graphicore please provide more details about what the API will be like to call and what it will return :)

To make the API available from within anguarJS we'll register a service like this:

angularApp.constant('glyphRendererAPI', glyphRendererAPI);

To get hold of the API from somwhere in angularJS, it can be dependency injected like any other angular module. For example:

function AppController($scope, glyphRendererAPI) {
    // do something
    var glyphSVG = glyphRendererAPI.get('uni123');
}   
 AppController.$inject = ['$scope', 'glyphRendererAPI'];

The API will probably have to use reference counting, to know when to stop updating glyphs, so a user of the API must give a hint when a once requested instance of a glyph got unused:

glyphRendererAPI.get('uni123');  // The reference counter for uni123 is at 1
glyphRendererAPI.get('uni123');  // The reference counter for uni123 is at 2

glyphRendererAPI.return('uni123');// The reference counter for uni123 is at 1, the glyph will still be updated
glyphRendererAPI.return('uni123');// The reference counter for uni123 is at 0, the glyph will not be updated anymore

What's missing:

• How do we propagate size information (if we need that). I think we can solve that when we are at the point. Most interesting cases are glyphs that leave their "box" like starting at a negative x or ending after the "advance width" or disrespecting the given em-height. Can we do "overflow: visible" with SVG? Otherwise, we would have to position the SVG inside of a div and use "overflow: visible" for that div.
• We don't even try to do text layout here, we just return glyphs by glyph name. So, the translation of a text to a list of glyphs will probably need some attention at one point.

[guiguru]

today’s clarifications and design decisions have been merged—directly or in an adapted form—with the relevant wiki spec pages.

[davelab6]

@graphicore and what will it return? elements?

[graphicore]

Most probably svg-elements, at least something that can go into the html DOM as display: inline-block maybe we have to do something about the overflow: visible issue I mentioned, then it's maybe a div or a span containing an svg (and potentially a bit more complex).

[davelab6]

I think a svg def element makes sense for use by svg use tags. With xref could even be via restful api On Feb 19, 2015 1:20 PM, "Lasse Fister" notifications@github.com wrote:

Most probably svg-elements, at least something that can go into the html DOM as display: inline-block maybe we have to do something about the overflow: visible issue I mentioned, then it's maybe a div or a span containing an svg (and potentially a bit more complex).

— Reply to this email directly or view it on GitHub https://github.com/metapolator/metapolator/issues/337#issuecomment-75106271 .

[graphicore]

The <defs> element is where the glyphs are stored, so that is private. The <use> element uses xlink to reference and display the glyphs. The API returns something along this line:

<svg>
    <use xlink:href="#glyphID"/>
</svg>

Intuitively, I wouldn't return just the plain <use> element because we need to wrap it in an <svg> to apply it to HTML. However, a plain <use> element can be arranged if it is helpful. A use element will be included somewhere in the return value for sure.

I don't think that a RESTful api via xlink can be very useful here, there's no update on change, afaik.

[graphicore]

the actual API is:

svgElement = glyphRendererAPI.get(masterName, glyphName);

// and to decrement the reference counter:
glyphRendererAPI.revoke(masterName, glyphName);

Also, the glyphRendererAPI will change the width of the returned SVG elements when the glyph width changes. The height of the svgs can be used to set the line height of the glyphs, via css for example, using the css height parameter.

I used it like so for that video on g+ https://plus.google.com/u/0/+LasseFister/posts/RuTZ3QAAwHn

var masterName = 'interpolated';
'metapolator'.split('').forEach(function(glyphName) {
    document.body.appendChild(glyphRendererAPI.get(masterName, glyphName));
});

[jeroenbreen]

@guiguru Monday I want to focus on • rubberbanding • select with ctrl/shift/cmmd

So there is no tool icon for the rubberbanding right? So where is the rubberbanding active? On the complete specimen panel (so all the white in the current design) or also outside? . In other words, can you start to drag somewhere in the parameters panel en end in the specimen panel? Was there also rubberbanding designed on other panels? In other words: I am standing for the choice to make 1 overall rubberbanding tool and look inside that function if you ment to select glyphs or something else (which could possible give quite difficult scenarios) OR make several rubberbanding tools (then there has to be a designated area for each, so by the first mouseclick I know which one whe are using). Doesnt the rubberbanding conflict with other mouse-events? I remeber in the glyph range, we want to be able to drag glyphs (to change the order). How do these two combine? Notice that in the Finder, there is a non-icon area, between icons. We don't have non-glyph areas right?

Is there a deselect all possibility?

btw I updated the "size-rope", this is the way it supposed to be right? I took the liberty to use pythagoras instead of a+b :) and 12, 3, 6 and 9 o'clock are active as well now.

[guiguru]

Monday I want to focus on • rubber banding • select with ctrl/shift/cmmd

OK, here is the feedback/bugs of today:

1. great progress
2. selecting glyphs works right now as if the shift key is down all the time; click on ‘n’, then on ‘k’ (with no ctrl/shift/cmd key down), the result now is n+k selected—the result should be k selected, the last one clicked (see Finder icon view);
3. a click on a selected glyph (with no ctrl/shift/cmd key down) should not deselect it;
4. /space is also a glyph in the master (thus selectable for edit)—as is all punctuation;
5. the underline is now all inside the metrics box, should be exactly outside;
6. that is a 3 pix underline; specced is 4; can it be blue please, for selected? red is definitely the color for updating;
7. when the specimen scrolls, the top control bar (with specimen choice, filter, font by) is fixed at the top.

So there is no tool icon for the rubberbanding right?

there is no icon tool button—to switch modes with—if that is what you mean.

btw, important: the default mouse pointer for the whole UI—and certainly in a specimen—is ccs value “default” (i.e. arrow, pointing north-north-west).

So where is the rubberbanding active? On the complete specimen panel or also outside? (so all the white in the current design).

it is active in the content area of the specimen (i.e. everywhere where master/instance glyphs can appear, but not in the specimen control bar).

In other words, can you start to drag somewhere in the parameters panel en end in the specimen panel?

no.

Was there also rubberbanding designed on other panels?

rubber-banding only works for 2-dimensional content. our masters and instances lists have vertical dragging (in the sequence and view columns) to do sweeping changes.

In other words: I am standing for the choice to […]

see below how I solve this…

Doesnt the rubberbanding conflict with other mouse-events? I remeber in the glyph range, we want to be able to drag glyphs (to change the order). How do these two combine? Notice that in the Finder, there is a non-icon area, between icons. We don't have non-glyph areas right?

you are very right about this, and here is the solution:

• the glyph boxes are the ‘icons’ and no rubber-banding can start within them; note that spaces are also glyphs;
• everything not covered by glyph boxes is whitespace in the specimen:
  • leading between the lines of text: I say let’s start with 20% leading—and min-leading of 8pix; put this leading also above the very first line and below the very last one;
  • margins between the paragraphs;
  • margins left + right of the specimen column—up to the left + right edge of the specimen panel;
  • at the last line of each paragraph, between the last glyph of that line, to the end of the line;
  • when the specimen does not scroll, between the leading under the last line and the bottom edge of the specimen panel.
• a drag started in whitespace starts a marquee selection (aka rubber-banding);
• a semi-transparent rectangle tracks the rubber-banding, until the mouse button goes up;
• all text-type of selection behaviour—from dragging and (double-/triple-)clicking—shall be suppressed.

Is there a deselect all possibility?

single click in whitespace.

btw I updated the "size-rope", this is the way it supposed to be right?

close, but no cigar. see below

I took the liberty to use pythagoras instead of a+b :)

I see the result and I think it is good. spec updated to reflect this.

and 12, 3, 6 and 9 o'clock are active as well now.

the area between 3 and 6 o’clock, and 9 and 12, still works the wrong way.

When just before touching the size rope control the display size is 80pt, and later on—while the control is being used—a microsecond before diamond is moved into the ‘blue-no change’ area, the size is tracking the diamond position to 234pt, 7pt, or godknowswhat, then all while the diamond is inside the area between 3 and 6 o’clock, and 9 and 12, the display size is 80. and when the diamond is released there, nothing has changed. that is why they are called the bail-out areas.

btw: it has to be a diamond (een ruit), a combination of up/right/down/left arrows, really. and please centre it vertically on the size text box.

[jeroenbreen]

Okay, got most of the comments covered I think. (will work on key selecting tomorrow)

the underline is now all inside the metrics box, should be exactly outside;

Not sure if you are talking about the above situation, if so: this is only the case now, because these are stil real letters. Once I'll use Lasses svg's then a the letter is always inside the box. If you were talking about the 4px itself, which gave a 4px space between lines, then I must compliment you for your keen eye. I solved this by giving the boxes a negative bottom margin of 4px.

About the whitespace and the rubberbanding. Not sure if you were talking about glyph-range-view only, or also about non-glyph-range-view (looks like the last). The problem I mentioned about the mouse-event conflict considers only the glyph-range-view in my opinion. Here is were you want to reorder by dragging, in the non-glyph-range-view you don't need to drag, right (only the dragging conflicts, regular clicking doesn't)? With this mindset I constructed the current rubberbanding.

[guiguru]

hey @jeroenbreen,

this is shaping up great. now for the next level:

• in general, when the mouse goes down (with no ctrl/shift/cmd key down), whether it is the start of rubber-banding or of a single click, the selection that exists up to then has to disappear;
• there needs to be feedback during rubber-banding of what is becoming selected; this is essential for users, so that they can see they are achieving their goal;
• the number of pangrams on the specimen should be equal to the number of masters that are viewed at any moment, so that there is at least a chance that each glyph is shown in each master; if you are fetching your pangrams from an online source: great, fetch more. if this is not the case and developing it will cost you 1 hour+, then I say: repeat the same pangram, according to the number of masters that are being viewed;
• are you using now leading between the lines of the pangrams? I think our users will appreciate it (with their high typesetting sensibilities); also there needs to be space to click for deselect all;
• the size-rope is really 97% there—yeah—just a few final touches:
  • there is only one diamond; when the rope is pulled out, there is no diamond in the centre point;
  • the text input field for the display size should be big enough for 4 digits;
  • please move the diamond control a bit (3pix, I guess) closer to int input field, so that it also looks like they belong together (ze hebben verkering).

the underline is now all inside the metrics box, should be exactly outside;

Not sure if you are talking about the above situation,

the underline should be out of the way of that descender, so that users can evaluate it without interference.

if so: this is only the case now, because these are stil real letters. Once I'll use Lasses svg's then a the letter is always inside the box.

then let’s wait until the real thing is there and solve it then.

If you were talking about the 4px itself, which gave a 4px space between lines, then I must compliment you for your keen eye.

hey, I measured it (and I measured it today again) ;^}

About the whitespace and the rubberbanding. Not sure if you were talking about glyph-range-view only, or also about non-glyph-range-view (looks like the last).

yes you are right. I was talking of the non-glyph-range-view.

The problem I mentioned about the mouse-event conflict considers only the glyph-range-view in my opinion. Here is were you want to reorder by dragging, in the non-glyph-range-view you don't need to drag, right (only the dragging conflicts, regular clicking doesn't)?

I thought about it carefully (just in case we get in trouble later) but I see no glyph dragging in the future of the non-glyph-range-view. so your implementation of start-dragging-anywhere for it is good (but note the points at the top of this comment);

It is clear to me that the glyph range itself needs work: design work. thus I ask to give me 24 hours to sort out its problems and define sharper what should be there for this release. it is good to see that rearranging works.

[jeroenbreen]

@guiguru okay thanks for the feedback. Probably your comments and the key-clicking will be done by today or tomorrow. Can you please formulate what's up after that. It really works for me (like we are doin now) if I can think about it for one or two days and discuss about it, before a really work on it.

[jeroenbreen]

oh and yeah mentioned 4 digits. At my computer it has 5 digits. Do you mean I have to make it smaller or is the font-size different on your computer? Just checked that my input field doesn't inherit font-size and font-family from my styles, so there probably is a browser/computer(?) standard for input fields? In that case, I shall give it a specific style. Maybe best if you just say: width of input fied + font-size.

[guiguru]

@jeroenbreen see what you mean. later today I will do that.

oh and yeah mentioned 4 digits.

this is what it looks like here (safari 7.1.3):

Maybe best if you just say: width of input fied + font-size.

better do this in one go when the visual design is there. for now just do your thing.

[jeroenbreen]

@guiguru Okay uploaded the corrections: • 4 digits displaying now • only 1 diamond, closer to the input • there is a dragging feedback (with big paragraphs this might get a little slow, I'm quite satisfied for now, but I might wanna optimize this at a certain point), waiting for GD instructions for that

• leading: I placed a temp border around the glyphs to illustrate something (hence also the leading is now 1/3, to illustrate it better). The area outside the borders, is the whitespace we talked about. Only, at this time, not all whitespace behaves as whitespace (clicking on it, too close to a glyph, makes you select the glyph). I am almost 100% certain this is the same 'issue' as the descenders we talked about. The browser places descenders and maybe other font area outside its box (the border borders the box), so here again: once we use svg (= image): what you see is what you get, regarding the area a glyph uses.

[guiguru]

@jeroenbreen point (1) the I wrote this morning (“the selection that exists up to then has to disappear”) really needs to be done, followed by (2) (the selection feedback—**but only of the glyph instancess that get ‘hit’—using the blue underlines).

• please right align the text in the size input

• leading: I placed a temp border around the glyphs to illustrate something (hence also the leading is now 1/3, to illustrate it better).

I see; nifty. I’d swear that this morning there was no leading at all. zero whitespace between the boxes.

The area outside the borders, is the whitespace we talked about. Only, at this time, not all whitespace behaves as whitespace (clicking on it, too close to a glyph, makes you select the glyph). I am almost 100% certain this is the same 'issue' as the descenders we talked about. The browser places descenders and maybe other font area outside its box (the border borders the box), so here again: once we use svg (= image): what you see is what you get, regarding the area a glyph uses.

I see your point. for now I would like to see it again, with 20% leading and no temp border.

[jeroenbreen]

There it is. As you can see in the picture, there is a whitespace, but as will you notice, because it is smaller then it was this morning, non of it is acting as a whitespace.

The unselecting on mousedown is on the list next, part of the (key)clicking stuff I planned.

[jeroenbreen]

@guiguru oh shit... I forgot the ctrl/shift/cmmd click was purely toggling. I just spent some time to make it - quite elegant I must say - set-selecting... We don't want this right?

[guiguru]

@jeroenbreen alas, no. else we just could have used standard text selections.

sorry, —ps

[jeroenbreen]

no problem, I could reuse a lot, its up already.

[guiguru]

that’s fast, and cool. (but take a look at shift + rubber-band)

[jeroenbreen]

shift + rubberband is up.

[guiguru]

@jeroenbreen, after thinking about it, I see that the image shown in the wiki for the glyph range-type specimen is pretty much it. specifically:

• adhere to the glyph boxes, no extra padding;
• generous leading/margin between the lines (33% or more, with a minimum of 12px);
• the same number of pixels that is used for the leading/margin is also used as horizontal margin between every glyph box;
• note the size control and the filter at the top.

but with the following modifications:

• forget about the bottom bar with buttons and glyph code editing;
• I would like to try what the glyph range looks like with proportional glyph boxes (instead of the fixed-width shown).

ah, and it is time to get the filter working, starting with the slide switch and the label ‘Strict’ and then on the algorithms (btw, the right-most position, the strictest, filters so much that it is much more efficient to put the characters that are in the filter text box straight on the specimen, just in the order they appear in the text box—really, really straight).

I will now do again a merge of what I wrote here to the wiki; got to keep them updated

[jeroenbreen]

• adhere to the glyph boxes, no extra padding; • generous leading/margin between the lines (33% or more, with a minimum of 12px); • the same number of pixels that is used for the leading/margin is also used as horizontal margin between every glyph box; • note the size control and the filter at the top. but with the following modifications: • forget about the bottom bar with buttons and glyph code editing;

That is done.

• I would like to try what the glyph range looks like with proportional glyph boxes (instead of the fixed-width shown).

I've placed two buttons on it, so you can try for yourself.

ah, and it is time to get the filter working, starting with the slide switch

Ok, check, a switch instead of the radio buttons.

and the label ‘Strict’

Ok.

and then on the algorithms (btw, the right-most position, the strictest, filters so much that it is much more efficient to put the characters that are in the filter text box straight on the specimen, just in the order they appear in the text box—really, really straight).

Don't understand this sentence completely.

What I understand of the strict+search is this (must admit the possibility I made up rules myself, missing rules you defined already):

For non-glyph-range-view: • if the search box is empty, everything of the specimen survives • if strict is 1 (right) -> every word containing at least 1 character of the search box survives • if strict is 2 -> every word containing at least 2 (or a ratio of the word-length?) survives • if strict is 3 -> every word with all its characters present in the search survives.

For glyph-range-view: • if the search box is empty, everything of the glyph range survives • every character in the searchbox survives. Now I placed them in the order corresponding to the font-info (the glyph range) itself (if you turn the logic around: (order of searchbox), then reordering of glyphs doesn't make sense anymore, right?).

[jeroenbreen]

Btw, I see some (already existing) technical problems with filtering and reordering...

I am using http://jqueryui.com/sortable/ to sort stuff. This is based on <li>s in a <ul>. Where the <li>s represent the objects in your model. By reordering, you adjust your model: perfect.

But when I filter on the <li>s, the model isn't represented completely and so it gets confused when you reorder stuff.

[davelab6]

and then on the algorithms (btw, the right-most position, the strictest, filters so much that it is much more efficient to put the characters that are in the filter text box straight on the specimen, just in the order they appear in the text box—really, really straight).

Don't understand this sentence completely.

I think @guiguru means that 'strict filter' means 'no filter' - it is a literal text input, what you type in the filter is what you see in the specimen view

I think it might be worth having a zero-th strict mode for this case.

[davelab6]

@guiguru I've filed issues for each item in https://github.com/metapolator/metapolator/wiki/working-UI-demo#the-whats-next-list so that each one can be discussed and tied to the concrete commits that resolve it :) I suggest just filing issues, rather than editing that list further

[guiguru]

@jeroenbreen, some quick notes to keep you going:

• the rightmost position of the strict switch is the strictest;
• 3 positions is enough, 4 is too much;
• I have touched up in the spec what the 3 positions mean;
• mid position: some glyphs is 2 glyphs;
• forget about the fancy stuff: guarantee of completeness, popup menu;

ah, the Font by: popup has to be removed for the glyph range

[jeroenbreen]

the rightmost position of the strict switch is the strictest;

okay, I got that the other way around, strange...

3 positions is enough, 4 is too much; I have touched up in the spec what the 3 positions mean;

Not sure if I understand the strictest right. Is it just: whats in the search is printed 1:1?

mid position: some glyphs is 2 glyphs;

So thats working correct rigth?

forget about the fancy stuff: guarantee of completeness, popup menu;

ah, the Font by: popup has to be removed for the glyph range

Okay will do, strange it slipped through.

[guiguru]

whats in the search is printed 1:1?

yes, because super-strict filtering would give you this result anyway: ‘really only these characters.’

[jeroenbreen]

Okay and the order is the order of the search box? In the non-glyph-range as well as in the glyph-range?

[guiguru]

Okay and the order is the order of the search box? In the non-glyph-range as well as in the glyph-range?

glyph range: yeah, better keep the order of the glyph range; non-glyph-range: filter box order looks better

[guiguru]

@jeroenbreen just a quick note from the call today (have not got time for a thorough review tonight):

• every specimen (all of them) repeats N times when N master (+ instances, for the metapolation specimen) have to be shown;
• when the filter is super-strict, an empty filter box still does not filter at all.

[jeroenbreen]

every specimen (all of them) repeats N times when N master (+ instances, for the metapolation specimen) have to be shown;

Is that for font by glyph, word and paragraph? For word and glyph it only makes sense when the repeated specimen starts with an other master than the first specimen right?

[davelab6]

In trying out the resize diamond widget and I think this is a great 'taste' for the deep interaction work @guiguru has done! :)

I wonder that it should work with stepping the size at a variable rate - bigger steps for larger sizes, and smaller steps for small sizes - eg for a type person, stepping from 11 to 14 px is a big jump, but 70 to 73 is a small jump, even though numerically both are +3.

The GNOME font picker has a modest attempt at implementing this idea that changes in font size is more meaningful for smaller sizes:

Also websites like http://type-scale.com also show typographers consider the steps in a harmonic way.

[guiguru]

every specimen (all of them) repeats N times when N master (+ instances, for the metapolation specimen) have to be shown;

Is that for font by glyph, word and paragraph?

all of them.

For word and glyph it only makes sense when the repeated specimen starts with an other master than the first specimen right?

good one. you are very right. apart from the ‘start’ to be a different one, so does need to be the ‘second’ (glyph or word). and ‘third’ (up to N). seems to be possible to do this by putting the masters (and instances) in a list that is a ring (in order they are in their display lists, instances before masters); and shift one position for each paragraph that is displayed

[guiguru]

In trying out the resize diamond widget and I think this is a great 'taste' for the deep interaction work @guiguru has done! :)

thanks @davelab6.

I wonder that it should work with stepping the size at a variable rate - bigger steps for larger sizes, and smaller steps for small sizes - eg for a type person, stepping from 11 to 14 px is a big jump, but 70 to 73 is a small jump, even though numerically both are +3.

I noticed something like that yesterday. My analysis is that the size changes too fast at smaller sizes, it needs to be slowed down there. at larger sizes (100pt and up) I think it is a real benefit that the control is so smooth: 1 pt change for 1 pixel of distance—I do not want to lose that.

The GNOME font picker has a modest attempt at implementing this idea that changes in font size is more meaningful for smaller sizes:

yes, variable input scaling is the answer. the gnome control has problems I avoided (limited input range in pixels, we got input range in the thousands).

so here is what I am thinking:

at size >= 100pt, 1 pixel input distance change = 1 pt size change

at size = 10pt (our minimum), 10 pixels input distance change = 1 pt size change

in between: constant variable input scaling (in pixels/pt). this can be as easy as

if ( pt size < 100 ) { input scaling (for the next input delta) = 100 / current pt size; } else { input scaling = 1; }

since during the pulling of the rope there is constant update events over short distances (that’s why it is pretty smooth) I think that can be an approximation good enough for jazz.

[jeroenbreen]

ok, updated 3 things:

1. the strict box: text visible when nothing in the search box, for all strictnesses
2. repeating of specimen, according to nr of fonts visible. Every new one starts with 1 further in the fonts array.
3. size rope, has a scaling growt now, related to the size you are starting with (note: not related to the current size. Is that how you designed it? )

Did you/Simon make a desicion yet about the fixed/unfixed width? So I can remove the buttons.

[guiguru]

the strict box: text visible when nothing in the search box, for all strictnesses repeating of specimen, according to nr of fonts visible. Every new one starts with 1 further in the fonts array.

yay!

size rope, has a scaling growt now, related to the size you are starting with (note: not related to the current size. Is that how you designed it? )

I could have been clearer: during the rope pulling, for every update event you handle, you re-calculate the input scaling out of the current size. if the rope is pulled to take the size from 200 to 20 then < 100 the input scaling changes continuously, and quite a bit (1–5)

Did you/Simon make a desicion yet about the fixed/unfixed width? So I can remove the buttons.

after the call yesterday I conclude: proportional width and border off. you are right that the border helps when aiming for whitespace to start rubber-banding, but the border is really in the way when evaluating the shape of the glyphs (an important job here). no, I do not believe a dynamic system (border under some conditions) can get it right (endless irritation for users).

thanks for providing the buttons to see the effect of the two choices, really useful

[guiguru]

I have merged all my input here, up to this point, back in the spec wiki.

I tested some things and found this:

1. shift/ctrl with rubber-banding does not work correct: you seem to demand that shift/ctrl was already pressed on the first select, for the second to add up properly; first press is not needed;
2. super strict filtering: although we put directly on the specimen what is typed, multiples should be weeded out type “aap”, display “ap”;
3. I just noticed the spec saying that the glyph range specimen is not shown for the metapolation specimen;
4. note that when the filter is in the middle strict setting and one character is in the filter box, it works like the least-strict filter

[davelab6]

On 26 February 2015 at 09:59, peter sikking notifications@github.com wrote:

I just noticed the spec saying that the glyph range specimen is not shown for the metapolation specimen;

Not sure this is needed for the demo

[guiguru]

Not sure this is needed for the demo

it means taking that option out of the popup list on the top-left (which picks the kind of specimen one looks at). does not sound so big to me.

[jeroenbreen]

I could have been clearer: during the rope pulling, for every update event you handle, you re-calculate the input scaling out of the current size. if the rope is pulled to take the size from 200 to 20 then < 100 the input scaling changes continuously, and quite a bit (1–5)

I did implement that now. But the way I handle it, causes a bug. This is the way I handle it:

1. catch the starting size (eg 80pt)
2. measure length of rop (30 px) > set new size (cacluated from the starting size) & set the factor we talked about
3. still draging, meaure lenth again (eg. 50) > set new size & set the factor. With this order of work, a longer length of rope, but with a smaller factor, can cause a smaller delta. Do you get it? So refering to something you said earlier about me saving hours and you do the logic: you solve it :)

shift/ctrl with rubber-banding does not work correct: you seem to demand that shift/ctrl was already pressed on the first select, for the second to add up properly; first press is not needed;

I cannot reproduce what you are describing. click/drag on 1 glyph, release -> (wait) -> shift + drag around another release. Is that what we are talking about?

I just noticed the spec saying that the glyph range specimen is not shown for the metapolation specimen;

I didin't dive into the metapolation specimen yet. So for now it is just the same directive. Is that the only difference? And are they communicating with each other (eg. have same fontsize, etc) -> if so I have to make some variables global.

note that when the filter is in the middle strict setting and one character is in the filter box, it works like the least-strict filter

ok. will do.