This is part of the old website. New website begins at fontforge.github.io
Are you a web developer? Help us migrate this page on Github
Eeyore had three sticks on the ground, and was looking at them. Two of the sticks were touching at one end, but not at the other, and the third stick was laid across them. Piglet thought that perhaps it was a Trap of some kind. ``Oh, Eeyore,'' he began again, ``just ---'' ``Is that little Piglet?'' said Eeyore, still looking hard at his sticks. ``Yes, Eeyore, and I---'' ``Do you know what this is?'' ``No,'' said Piglet. ``It's an A.'' ``Oh,'' said Piglet. -- A. A. Milne, 1928
The House At Pooh Corner``Not O, A,'' said Eeyore severely.
Font design can be a Trap, but I find it a rather pleasant one. Caveat utor.
FontForge allows you to create and modify postscript, truetype and opentype fonts. You can save fonts in many different outline formats, and generate bitmaps.
| Mac | MS/Windows | VMS | from source | Uninstalling |
A font editor is a progam designed to creat and modify fonts.
The most obvious aspect is that it is a drawing program like FreeHand, Inkscape or Illustrator which lets you draw the outlines of your letters. Unlike other drawing progams it expects you to draw many pictures at once (one or more for each letter) and collects them into a database.
It allows you to describe the way these pictures interact with each other (if you put one picture after the other then they should normally be separated by a certain distance -- the font's metrics, or if these two pictures are placed adjacent to one another then they turn into a third -- the font's ligatures, and so on).
Finally a font editor will bundle up all the pictures you have drawn, and all the metadata about how those pictures fit together, and will turn that bundle of stuff into a font that your computer can use to display text.
Most simply a font is a collection of glyphs. But computer fonts must contain more than this, at the least they must also contain information on how to map an input string of bytes into an output display of visual glyphs. This mapping is called an encoding. Many fonts will also contain rules for how adjacent glyphs should be arranged. For instance, in fonts for the latin alphabet, there is often a rule saying that if "f" and "i" are adjacent then a special glyph, a ligature of "f" and "i" should be used instead. Fonts for latin letters generally do not require such rules (but can be enhanced by them), fonts for other scripts like arabic require them.
What's the difference between a character and a glyph?
A character is a concept and a glyph is a reification of that concept. The letter "A" is a character, while are all glyphs that represent an "A". In latin fonts there is often a single glyph for every character and a single character for every glyph, but not always -- in renaissance printing there were two glyphs for a lower-case s, the short and the long s. Whereas a ligature is an example of a glyph that represents two (or more) characters. In arabic most of the letters (characters) have at least four different glyphs, the appropriate glyph being determined by the letters around it. Here are four forms of the arabic character "seen" .
What is an outline font? What is a bitmap font?
Each glyph in a font has a shape and there are various ways of describing that shape on a computer. PostScript and truetype fonts generally describe the outline of the shape and then color in the interior of that outline, this coloring process is called rasterizing. On the other hand a bitmap font describes each glyph by drawing a picture of that character on a rectangular grid of pixels. There is a third type, a stroked font, where each stem of the glyph is represented by one line down the center of the stem, and the line is later drawn with a certain width. Most of the time we will not deal with stroked fonts directly (the Expand Stroke command can be used to turn them into outlines), but if you wish to edit stroked fonts, see the section on multi-layered editing.
|
|
|
An outline is composed of a set of contours or paths. In the picture on the above left the letter A is described by three different paths. The main one is on the outside and the two smaller ones are internal. Each of these paths is composed of a series of (Bézier) splines and line segments. FontForge can handle cubic and quadratic splines. PostScript fonts use cubic splines, TrueType fonts use quadratic (SVG fonts can be either).
Each cubic spline is defined by four points, two of which mark the end points of the spline and two more to describe the slope of the spline at those end points. Here are two cubic splines with all their points shown:
The points which describe the slope are called control points. They are represented here (and in fontforge) by little colored x's. Moving a control point will change the shape of the spline, but it will not alter where the spline begins or ends.
A series of splines and lines are joined together to make a path. There are several possible ways to make these joins as is shown in the example to the right. In each case we have three points in approximately the same relative positions. The three points are joined by splines or lines, but the type of joins alters the appearance of the connections.
In the first case there are no control points and the result is two straight lines, in the second case there is a line and a curved spline which are tangent at their point of intersection, in the third case there are two splines which are again tangent at their point of intersection. The point of intersection in the first case is called a corner point, and the incoming and outgoing splines or lines may be in any orientation with respect to each other. This is represented in fontforge by a square box. In the second case the point of intersection is called a tangent point, it is represented by a triangle. The third case is a curved point and is represented by a circle.
FontForge can also edit quadratic splines (the splines used in truetype fonts), here there is only one control point and it controls the slopes at both end-points. Because of this quadratic splines cannot bend in as many ways as cubic splines (the first spline above left would need at least two quadratic splines to draw), and you will often need more splines to achieve the same curve. You can control whether a font contains cubic or quadratic splines with the Element->Font Info command.
There are many different types of splines in the world. The ones described above are Béziers -- these are numerically simple and have a number of nice properties -- which is why they are used internally in fonts. However, there are some even nicer splines. It is easy to give Bézier splines the same slope on either side of a point, but a curve will look much nicer if it has the same curvature on either side of a point. Clothoid splines have this property.
Raph Levien has kindly donated to the open source community a library for converting clothoid splines into Béziers.
Clothoid splines are much easier to work with than Béziers -- there are no control points, just a sequence of on-curve points, and magically a beautiful curve will appear between them. FontForge can either edit a curve as a set of Béziers or as a set of clothoids.
A path is closed when it comes back and joins its start. All paths in an outline font should be closed. Once a path is closed in may be said to have a direction, essentially this may be thought of as "Was the path created in a clockwise or a counter-clockwise fashion?" (this is actually a little simplistic, if a path intersects itself, as in a figure 8, then the direction cannot be described as either clockwise or counter-clockwise, but most paths do not self-intersect (and paths in a font SHOULD NOT self-intersect) and we will simplify our life by pretending that we can call paths clockwise or counter).
When time comes to draw our outline glyph we want to make dark everything in the interior of the outline. But let's look at the outline of our A above. We have two paths inside the main outline path, and we want the interior of those two paths to be white rather than dark. How do we make this distinction? We do it by the direction of the paths. Consider any point in the glyph. If we draw an imaginary line from that point out to infinity (in any direction) and count the number of times we cross a path, each time we cross a clockwise path we add one to our count, each time we cross a counter clockwise path we subtract one. If the result of our count is non-zero then we color the point dark, otherwise we leave it white. So to make the A above work we make the outer path be clockwise and the two inner ones be counter-clockwise (Things could be done the other way around, but the convention is that the outer path should be clockwise).
All of these points (both the end points and the control points) are described mathematically. Each point is positioned on a cartesian coordinate system which has its origin on the glyph's baseline (the line on which letters without descenders rest). Most font formats expect coordinates to be integers between -32768 and 32767, FontForge uses real numbers internally but (usually) rounds to the nearest integer when generating a font file.
Generally it is a good idea to restrict yourself to integral coordinates. TrueType fonts can only contain integral coordinates so if you use a non-integral value FontForge will be forced to round it to an integer and this will alter the shape of the curve. PostScript fonts can contain non-integral values, but the various formats are optimized for integers. So use integers when you can. If you need more precision you can increase the "em-size" of the font.
When displaying a font we use the word "em" to represent the size of the font. If a font is displayed at 12points then 1em will be 12points. If the font is displayed at 18points then an em will be 18points. (traditionally a 12 point font is one where the metal slugs are 12 points tall -- or where the baseline to baseline spacing of unleaded text is 12 points, so an em was the size of the metal.).
When designing an outline font, you can no longer think in terms of points -- these fonts are scalable and can be any pointsize. You must think in terms of the em and fractions of the em. When you create a font you choose how many internal units (called "em-units") to use to represent 1 em -- this number is called the "em-size". In most PostScript fonts there are 1000 units to the em, TrueType fonts often have either 1024 or 2048 units to the em (TrueType recommends that you use a power of two). But you can choose any (positive) number you like (well, as long as it is less than 32767), the numbers above are conventions not requirements).
Suppose you have a dash in a PostScript font, and that dash is 500 units long, and the font has 1000 units to the em. Suppose a someone displays that dash at 12 points. Then that dash will be drawn with a length of 500/1000 * 12 = 6 points. On a 72 dot per inch screen where a pixel is almost exactly one point, the dash will be 6 pixels long.
Every glyph has its own coördinate system. The font's baseline (the line upon which most latin glyphs will rest) is 0 in the vertical direction. The horizontal origin is where the glyph will start being drawn (what is "drawn" will usually be empty space for a short while -- as there is usually some space between the origin and the edge of the glyph). This horizontal distance between the origin and the leftmost edge of the glyph is called the left side bearing (it may be negative, positive or zero). All glyphs have a width (sometimes called an advance width), this is the distance from the origin of the current glyph to the origin of the next. The distance between the right edge of the glyph and the width is called the right side bearing.
CJK text (Chinese, Japanese or Korean) can be written either vertically or horizontally, and so CJK fonts usually have a vertical advance width as well as the more common horizontal advance (and concomittant top and bottom side bearings).
A glyph like "g" or "y" extends below the baseline, this is called a descender, while a glyph like "k" or "l" extends above the x-height, this is called an ascender. Most latin (and greek and cyrillic) fonts have certain standard heights: the height of a lower case letter (without an ascender) is called the x-height, the height of a capital letter is called the cap-height, the height of the ascenders is called the ascender height (some, but not all, fonts have the ascenders and capitals at the same approximate height). Often these will not be exactly the same for all glyphs, the letter "O" is usually slightly taller than the letter "I", but they both are within the range of the cap height for the font.
The font itself has an ascent and descent associated with it. In the old days of metal type nothing could ascend above or descend below these values, nowadays accents and ascenders may reach above the font-wide ascent and descenders below the descent, but the concept is still a convenient one to retain. It is true that in almost all cases the glyphs will not ascend above or descend below the font-wide ascent and descent. The sum of the ascent and descent is the size of the font. The point size of a piece of metal type was determined by this value (essentially the height of the metal block holding the glyph). In a postscript font the local coordinate system is independent of the final size at which the font will be drawn.
FontForge can produce many font types. What's the difference?
PostScript is based on a cubic spline technology, while TrueType is based on a quadratic technology. Cubic splines are generally easier to edit (more shapes are possible with them). Any quadratic spline can be converted to a cubic spline with essentially no loss. A cubic spline can be converted to a quadratic with arbitrary precision, but there will be a slight loss of accuracy in most cases.
Within FontForge a font may contain either cubic or quadratic splines. These are converted to the appropriate format when a font is generated.
The other major difference between the two is how they solve the problem of drawing nice images at small pointsizes. PostScript calls this "Hinting", while TrueType calls it "Instructing" a font.
Unfortunately the word "OpenType" has come to have several meanings.
The first meaning describes the glyph (and spline) format of the font. In this sense Open Type is just a postscript font put into a truetype file format -- From the outside it looks like a truetype font except that the outline descriptions are postscript Type2 font descriptions rather than TrueType. Technically it is a CFF font inside an sfnt wrapper.
In a second sense of the word OpenType refers to a set of tables containing advanced typographic information. These tables may be added to either fonts specified with quadratic splines (truetype) or fonts with cubic splines.
Finally MS Windows uses an OpenType icon for a font if that font contains a 'DSIG' (Digital Signature) table.
To make things even more confusing the OpenType specification includes the old TrueType specification, so technically any TrueType font can be called an OpenType font.
FontForge does not support the DSIG table (if you want one there is a free
tool from MS which will add one). When generating a font, FontForge uses
the term "OpenType (CFF)" to represent a PostScript (CFF) font inside an
sfont wrapper. To include OpenType typography tables you would press the
[Options]
button and select the [] OpenType
check
box.
SVG (Scalable Vector Graphics) provides a relatively new font format, written in an xml dialect. SVG fonts can be either cubic or quadratic (or can use both, but FontForge is limited and will force a font to be either all cubic or all quadratic). SVG allows for two different types of fonts, one corresponds roughly to PostScript Type1 fonts, and the other, roughly to PostScript Type3 fonts.
Back in the early days of PostScript, the Type1 format was proprietary, only Adobe could make Type1 fonts, but anyone could make Type3 fonts. Type3 fonts were unhinted, but could include any postscript command and so could produce a wider range of pictures (multi-colored glyphs, stroked glyphs, glyphs based on scaled images, etc.). Most of the time these extensions are unnecessary, and the disadvantage of being unhinted is onerous -- but sometimes you want to play. If you compile FontForge with multilayer set you will be able to create type3 fonts.
These were the standard stand-alone PostScript fonts of the '80s and '90s.
These use a slightly different internal format (a more compact one) to express the same information as type1. This is the format that lives inside a CFF font which lives inside an OpenType font.
This is the font format that is designed to store PostScript Type2 information. It is most commonly found inside an OpenType (PostScript) font.
This is another way of specifying typographic information (like ligatures, kerning, glyph substitutions). It appeared before OpenType and is only used on Apple computers. It is based on state machines and is a little harder to work with than OpenType.
At small pixel sizes, the process of drawing the interior of an outline font is quite difficult to do well. PostScript and TrueType have different approaches to the problem of providing extra information to the rasterizer about how to draw small fonts.
|
|
Adobe also has a mechanism for handling dished serifs called flex hinting. This means a curve that is only slightly deformed from the horizontal (or vertical) will display as a line at small point sizes and as a curve at larger ones. FontForge will use these when it seems appropriate.
The original version of hints did not allow them to overlap, this meant that most serifs could not be described, Adobe then developed a mechanism called hint substitution which allows for different sets of non-overlapping hints to exist in different parts of the glyph. There are still shapes which cannot be fully hinted, but hint substitution is an improvement. The Hints->AutoHint command will figure out what stems overlap and where to change the current set of hints. The Hints->Hint Substitution Pts command will also figure where hint changes should occur, and the Hint Mask pane of the Point Info dialog gives the user direct control over this.
Most recently Adobe has provide a means to control the counters, the spaces between stems, in a glyph. The original Type1 description provided support for the horizontal counters in "m" and the vertical counters in "E" but more complex shapes could not be dealt with. Counter Hints (in a type1 font) may only be used with non-latin (non-greek, non-cyrillic) glyph sets, in type2 (OpenType) things are a bit more complicated,. FontForge will generate counter hints when appropriate.
Adobe provides some font-wide hinting mechanisms. The two most obvious are
the BlueValues and StemSnap settings in the
private dictionary. BlueValues provides
a list of vertical zones in which interesting things happen (so in a latin
font this might include the ascender height, the cap-height, the x-height,
the baseline and the descender height. At small point sizes everything within
one of these zones will snap to the same height, while at larger point sizes
the heights will be slightly different (for instance an "o" and an "x" usually
have slightly different heights, but displaying that at a small point size
would be ugly). Similarly the StemSnap variables specify standard stem widths
for the font. FontForge will try to guess reasonable values for these. It
also allows you to override these guesses and
specify your own values. For a more
comprehensible description of the private dictionary and what it can do,
look at
Adobe's
Type1 font specification.
FontForge's
AutoHint command will work better if
the BlueValues have been set. So before running AutoHint go to
Element-> FontInfo-> Private to
set this array. After AutoHinting you should regenerate the StemSnaps (also
at Element-> FontInfo-> Private).
Grid Fit M |
On the other hand, True Type says that figuring out what pixels to turn on would be a lot simpler if only the points and the splines were in the right place (ie. at pixel boundaries). And so True Type provides a set of instructions that move points around until they are positioned appropriately for a given size.
FontForge's hinting of True Type (properly called "instructing") is based on the stem hints also used by PostScript and on diagonal hints. It uses these hints to determine which points to move and where to move them.
When FontForge reads in a TrueType font it will store the instructions used, and when it next generates that font it will use those instructions -- provided no significant change has happened to a glyph.
Most of my hinting user interface is designed with PostScript fonts in mind.
In addition to a set of outlines (splines) glyphs may be built out of references to other glyphs. This is especially handy for the accented glyphs, "à" can be made up of a reference to the "a" glyph and another reference to the "`" glyph. This can result in significant space savings, and in ease of design (if you change the "a" glyph after making a reference to it the "à" glyph will automatically change too, whereas if you just copied the "a" you would have to recopy it.
FontForge has three commands for manipulating references, and one higher
level command for building accented glyphs. The
Edit->Copy Reference
command will put a reference to the current glyph into the clipboard, which
a subsequent
Edit->Paste
command will
install as a reference. The
Edit->Unlink Reference
command will turn a reference in a glyph into it's component splines.
The Element->Get Info
command (when applied to a reference) will bring up a dialog showing
you what glyph is referred to, and allowing you to bring up an editing window
on that glyph. Finally the
Element->Build->Accented
Glyphs
command will figure out what glyphs should be refered to
to build this composite glyph, and then will make those references and position
them appropriately. So if "à" were selected and you did a
Element->Build->Accented
Glyphs
command, FontForge would make a reference to "a" and another
to "`", and place the accent above the letter, and centered on it.
Some bitmap formats (OK, only one that I'm aware of) support references, so FontForge allows references in bitmap glyphs as well as in outline glyphs.
Sadly life is not always that simple. The references FontForge uses internally cannot always be converted into something equivalent in the output font. Generally this causes no problems (FontForge will simply unlink the reference in the output, which just makes the font a little bigger, but it has implications for instructing TrueType, and, to a lesser extent, hinting PostScript. Most people can ignore this, but if you are interested follow this link).
Most font formats require that a glyph contain either a set of outlines (or bitmap rasters) or a set of references. FontForge allows glyphs with a combination of the two, but, as above, when it comes time to output the results, FontForge will clean up the glyph (generally by unlinking references) so that it can be output in the current format.
A font may have several layers. When FontForge creates a new font it will have 2 real layers (the foreground and background layers) and a sort of half-layer for guidelines which is shared by all glyphs. In normal fonts all glyphs have the same number of layers (This is not true of Type3 fonts, and I'll talk about them later.)
Both the foreground layer and the background layer have certain predefined meanings: The foreground layer is the default layer for dialogs where there is no clear way to specify a layer. The background layer can contain all sorts of stuff, basically whatever you want it to, but any images in it may be autotraced into the foreground layer.
You may add other layers with the
Element->Font Info->Layers
pane. Each layer may have a name and a different kind of splines
(quadratic or cubic).
One potential use of addtional layers: Many people find it easier to edit
using cubic splines but like to produce truetype fonts with quadratic splines.
You can use one layer to hold the cubic splines and another to hold the
quadratics. There are commands for comparing layers
(Element->Compare Layer To
Layer
) and others for copying one layer to another (and adjusting
the splines to fit the new layer:
Edit->Copy Layer To
Layer
).
It seems a shame to have both a valid cubic and a valid quadratic font in
a database and only be able to produce a font from one of them, so the font
view will allow you to switch between layers
(View->Layers->*
)
and File->Generate Fonts
command
will allow you to output whatever layer you want into the font. (Note that
all layers will share the same hints, instructions, character set, bitmaps,
etc. It is only the outlines which differ.) Furthermore, you may choose to
store all the layers of a font into an sfnt (TrueType / OpenType font) with
the []Layers
checkbox of the
PfaEdit table of the [Options]
dialog.
Most people aren't interested in editing Type3 PostScript fonts (nor the equivalent SVG font), but if you want to, FontForge can (you must configure it to do so however, but default it won't). Here each layer represents a different drawing operation, and may specify a different color, stroke, fill, etc. Layers are not font-wide, each glyph has its own set of layers (which are not named). You can create new layers with a popup menu in the layers pane of the outline view.
In FontForge guidelines live in their own mini-layer (it isn't a full layer because all glyphs share the same set of guidelines rather than having an individual layer for each glyph). It can be edited just like any other layer and you may have guidelines of any shape you desire. You may also drag out horizontal and vertical guidelines from the edges of the outline glyph view.
A script is a collection of letter shapes and rules for putting letters together. For instance the latin script consists of the letters A-Z, written left to right, along with a transformation from upper to lower case, a few ligatures and rules for generating accents. Arabic is a script consisting of its own character set, written right to left, along with transformations for initial, medial, final and isolated forms, many ligatures and rules for placing vowel marks.
Within fontforge every glyph will have a name. Generally the glyph name will be something that provides information about what the glyph looks like so the name for the glyph representing "9" is "nine". Adobe has established a standard for what names may be assigned to what glyphs, and when producing a font for general use it is best to stick to that standard (Acrobat uses the glyph names and recognizes the standard ones. If you try and use "neuf" for "nine" Acrobat will not recognize it and surprising things will fail).
Adobe's standard provides reasonably mnemonic names for most latin and greek glyphs (to English speakers anyway), some rather incomprehensible names for cyrillic and hebrew (afiiXXXXX) and identifies most other glyphs by unicode code point (uniXXXX or uXXXXX where "X" represents a hex digit and XXXX is the unicode code point in hex).
If you are an english speaker and you are working with latin glyphs this is fine and dandy. But if you are French you might wish that "adieresis" were named "atréma" -- for that matter even if you are an English speaker you might prefer it to be named "aumlaut". No matter who you are you might prefer more mnemonic names for the code block you are working on.
FontForge has a concept called a namelist, each of which is simply a mapping from unicode code point to name. Several namelists may be defined, different lists may apply to different fonts and a font may have all its glyphs renamed from one namelist to another.
Namelists can also help navigating in a font. Even if a list does not apply to a given font its names may be used in the goto dialog to find glyphs. So if you've loaded a french namelist you can search for "atréma" and FontForge will show you the glyph "adieresis" or "uni00E4" or "aumlaut" or whatever.
A few caveats: Adobe's glyph name standard expects all glyph names to be in ASCII characters. Syntactically postscript permits a wider range of glyph names, but if you use non-ASCII characters some rasterizers might have problems. Best to keep non-ASCII names within fontforge (and rename glyphs to adobe's standard names before generating a font).
OpenType (and Apple Advanced Typography) allow various transformations to be applied to the input glyph stream to produce an output glyph stream. These transformations might include forming ligatures, kerning glyphs closer to each other, attaching vowel marks or diacritics to letters, conditionally replacing one glyph with another depending on the glyphs around it, etc.
The commands for each transformation are stored in what are called lookups. If you were designing a set of lookups to handle latin ligatures, you might have one lookup for ff, fl and ffl -- ligatures that happen almost all the time, another for fi and ffi -- ligatures which don't happen in Turkish but do in other languages, and lookups for ct and st -- ligatures which rarely happen in English but are more frequent in German (I think).
A Feature is a tagged collection of lookups. The tags are all 4 letter sequences (like 'liga') with standardized meanings. The 'liga' tag means standard ligatures. The 'dlig' tag means discretionary ligatures, and 'kern' means kerning. There are many others.
Every script (latin, cyrillic, han ideographs, ...) will have its own set of features that are meaningful to it. Sometimes things will be even more complicated, and each language within a script will have it's own set of features. In the example above we might assign scripts, languages, features and lookups thusly:
| Script | Language | Feature | Lookups | Comments |
|---|---|---|---|---|
| latn | default | liga (standard) | lookup for ff, fl and ffl | |
| lookup for fi and ffi | ||||
| dlig (discretionary) | lookup for ct and st | |||
| Turkish | liga | lookup for ff, fl and ffl | Lookups may be shared, so this can be the same lookup as above (Turkish distinguishes between i and dotlessi and fi ligatures hide this distinction.) |
|
| German | liga | lookup for ff, fl and ffl | ||
| lookup for fi and ffi | ||||
| lookup for ct and st | Lookups may even be shared by a different feature type, so for English and Spanish ct might count as a discretionary ligature, one rarely used, while in German it mght be more common and be part of the standard ligature set. |
The default language means any language in the script which is not specifically named. So in the above example the default language would be any language except Turkish and German that might use the latin script.
It is also possible to have a default script. The digits 0-9, are used in many writing systems, not just Latin and are considered Common to most scripts. If you have lookups which apply to the digits (conversion to oldstyle digits, or to proportional digits, or to superscripts...) you should attach those lookups to features in all scripts (and languages) that could use them, and to the default script (just in case).
| Script | Language | Feature | Lookups | Comments |
|---|---|---|---|---|
| latn | default | pnum | proportional number lookup | |
| onum | old style number lookup | |||
| subs | subscript lookup | |||
| Turkish | pnum | proportional number lookup | ||
| onum | old style number lookup | |||
| subs | subscript lookup | |||
| German | pnum | proportional number lookup | ||
| onum | old style number lookup | |||
| subs | subscript lookup | |||
| cyrl | default | pnum | proportional number lookup | |
| onum | old style number lookup | |||
| subs | subscript lookup | |||
| DFLT | default | pnum | proportional number lookup | |
| onum | old style number lookup | |||
| subs | subscript lookup |
There are roughly 15 different types of lookups which contain different information. Different kinds of lookup are needed to specify ligature data, glyph substitution data and kerning data.
Lookups may be specified with the Element->Font Info dialog
I talk above about lookups as if they were simple things. Unfortunately they aren't. Each lookup is composed of "Subtables" which actually do the work.
A lookup may contain several subtables. Most contain exactly one. (If a lookup contains no subtables it will do nothing).
I said there were about 15 kinds of lookup, there are even more kinds of subtable. For instance a subtable which specifies glyph to glyph kerning is different from one which specifies glyph class to glyph class kerning.
At first glance the subtable may seem an unnecessary complication, but it turns out to be desirable for one lookup to contain several kinds of sub-table data. For instance, a kerning lookup might include one subtable providing glyph class kerning, and then another subtable providing exceptions to that on a glyph by glyph basis.
When a word processor deals with text, it will figure out what script is in use in the text. Somehow it will figure out what the language is (maybe it will just assume the "DFLT" language, maybe the user told it the text was in French, maybe the locale is Spanish, ...).
In any script/language some features are applied by default, while others may be applied at the user's discression. So in English the "liga" feature should always be applied, while the "dlig" feature should only be applied if the user asked for it. (Not all programs follow this at the moment, but that's the theory).
The word processor will build up a list of features that might be active. Then it looks in the font and sees which of those features are available for this script and language. In turn each feature is composed of lookups, and all lookups in all active features will be marked as active.
Lookups will be executed in the order in which they occur in the lookup list (which is also the order shown in the Font Info->Lookup pane, but may be quite different from the order in which the features were listed). And all active lookups will be executed.
This ordering can be important. If you have both a small-caps lookup and a ligature lookup active, and the text is "fi" then the order of the lookups will probably matter. If the small-caps lookup happens first then the "fi" will become "FI" and the ligature feature will not be applied. If the ligature happens first then you will see an "fi" ligature for which there is probably no small-caps glyph. In one case you get small-caps, in another a ligature. Probably, here, you would like the small-caps lookup to happen first.
Lookup subtables make life even more interesting. When a lookup is executed the subtables within that lookup are activated in turn until one succeeds. After that no further subtables will be applied.
So in the kerning example mentioned above, you would want to put the special case glyph to glyph subtable first, and then the glyph class to class subtable second. When a special case combination occurs the first subtable will succeed (and kern the combination) and the class subtable will not be used. For combinations which aren't special cases, then the first subtable will fail, and the second will be applied.
Up till now I have spoken as there were one list of lookups. That was a simplification. There are two broad classes of lookup, and two lists. There are those involved in manipulating the glyphs themselves (glyph substitution, ligation, decomposition, etc.) and those involved in positioning glyphs relative to others (kerning, mark attachment, etc.).
The GSUB table contains all the glyph substitution lookups and all of them will be processed before any positioning lookups are attempted.
The GPOS table contains all the glyph positioning lookups.
Anchor points allow fine control of the positioning of two (or several) glyphs. There are several different styles of attachment based on anchors: cursive, mark to base, mark to ligature and mark to mark positioning. The first style is used to join glyphs in flowing scripts (cursive) where the exit from one glyph joins the entry point of the next. In the second style one of the glyphs is the base glyph, and it will be positioned normally, the other glyph which will often be a diacritic or vowel mark will be positioned so that the anchor points in each glyph are coincident. Mark to ligature behaves similarly to mark to base except that there may be more that one attachment point on the ligature depending on which component a given mark is connected to. Finally, mark to mark allows you to position two marks with respect to each other (as you might need to do in vietnamese or hebrew where you may get several marks for one glyph).
That is badly said. Consider the following two glyphs and how they are joined to make the final result:
| + | => |
The grave accent has been raised and moved to the right so that its anchor point is positioned where the anchor from "a" was.
FontForge does not compose these glyphs (well, it can, but that's a completely different area), instead it provides information within the font to a text layout program so that the program can do the composition.
The example above is unlikely to be very useful since most latin fonts contain pre-composed a-grave glyphs, but the same concepts apply to arabic and hebrew where the number of variants is larger and the precomposed glyphs fewer.
That's roughly how anchor points are used. Now the mechanics.
Each of the different attachment styles mentioned above (cursive, mark to base, mark to ligature and mark to mark) is a different type of GPOS lookup. If you want to do attachment positioning you must first create the appropriate lookup (Element->Font Info->Lookups->GPOS, then a lookup subtable, and then an anchor class within the lookup subtable. An anchor class is specified by providing a name for it (in the above example the class was called "Top").
Cursive attachments are a little different from the other attachment types. Each glyph has two attachment points, an entry and an exit (instead of just the one shown in the mark to base example above). The text layout program will attach the exit point of one glyph to the entry point of the next.
A glyph may contain several Anchor Points, but only one for each mark to base anchor class (ligatures may have more than one for a class, and 'curs' and 'mkmk' classes will usually have two). Inside a glyph may create a point with the Point->Add Anchor command. You must specify an anchor class, and whether this point is in a base glyph or in a mark glyph, and a location. So in the example above the anchor point in "a" has class "Top" and is a base glyph, while the anchor point in "grave" also has class "Top" but is a mark glyph. There may be many base glyphs with an anchor point named "Top" and many mark glyphs also with "Top" anchor points. Any base glyph with a "Top" anchor point maybe composed with any mark glyph with a "Top" anchor point. So instead of specifying the exact composed form for all possible combinations we specify far fewer anchor points for the same effect.
But life is not really that simple. Ligatures may need several anchor points of the same class (one above each component for example). When you create your anchor point you may say that it is to be in a ligature, in which case you will also be asked for a ligature index -- a number running from 0 to the number of components in the ligature -1. This allows you to position several anchor points with the same class. The text layout program will place the first mark over the first anchor point, the second mark over the second and so on (this is a gross simplification).
Finally you may need to position two marks based on the same anchor point, for example the glyph has a diaeresis and a macron over it. Both of which might normally be positioned with the Top anchor class. Instead we define a special class for positioning one mark with respect to another. When creating the anchor class specify a tag of 'mkmk' (mark to mark) and call it something like "TopMark". When you create a new anchor point for diaeresis you specify that it is a base mark and you position it above the glyph, while the new anchor point in macron should be of type mark and should be positioned at the same place as the "Top" anchor point. Thus when given the sequence of glyphs "a diaeresis macron" the text layout program should position "a" normally, position "diaeresis" so that the its Top anchor point is where "a"'s is, and position macron so that its TopMark anchor point is where "diaeresis"'s is.
Anchor points may be selected, dragged, transformed, cut, copied and pasted.
To a user of the latin alphabet it makes sense for the vertical origin of a glyph to be the baseline on which most letters rest. This means that if you change the pointsize of a glyph it will still line up properly. This is so obvious we don't even think about it. But if you put the vertical origin at the top of the letter then the letters will be aligned quite differently, and to our eyes, unexpectedly.
Different scripts have different expectations of how glyphs should be aligned. In latin (cyrillic, greek, arabic, hebrew, etc.) the alignment point, the baseline, is somewhere in the middle of the possible extent of a glyph -- that is the script has both ascenders above the baseline and descenders below it.
But not all scripts are like that. In Devanagari the alignment point is near the top of the glyph -- indeed most glyphs will draw in the baseline explicitly. If you change the pointsize you want glyphs to line up on this line, and not down at the bottom of the glyph .
In CJK ideographs the baseline is usually drawn at the bottom edge of the square which contains the glyph.
However if you try and typeset these different scripts together with their baselines in the same place you get a mess: . It would be much nicer if it were possible to say that these different scripts have their baselines in different places so that the glyphs can fit together reasonably:. Both Apple Typography and OpenType allow for this. There is a baseline table which says how the baselines for each script (or each glyph) should be aligned with respect to other baselines.
The font view displays all the glyphs in the font (or all that will fit in the window). Every line has two parts, at the top is a label, often small clear letters, underneath that, somewhat larger is a 24 pixel rasterization of the font you have designed. As you edit a glyph in an outline glyph view its small version in the font view will change as you work.
Double-clicking on a glyph will bring up an outline glyph view of that glyph which will allow you to edit it.
Selecting several glyphs will allow you to apply various operations to all of them, or to cut and paste them.
Fonts do not need to be for the latin alphabet alone. Below is a view of one of Wadalab's public domain Kanji fonts...
Another Wadalab font encapsulated in a CID keyed font
The outline view is probably the most complex view in FontForge. This is where you actually edit the splines (Bézier splines) that make up your glyphs.
You may have a background image loaded into the view to help you trace out the shape you are working on (it is displayed in grey). There are various grid lines visible, some created by default (the baseline, the ascent line, the descent line, and a line at x=0), you may add others yourself.
There is a layer showing the glyph's hints.
In the foreground are the splines and points of the glyph itself, and the width line (you may adjust the glyph's width by moving this line). If a point is selected then its control points will be displayed.
To the left of the main window (the image below shows them on the right, that was just to keep them from crowding things, you can move them around) are two palettes, one a palette of tools, and the other a palette controlling what layers (foreground, background, grid, hints) are visible and editable.
The bitmap view is similar to the outline view above. It also has a tools and layer palette.
This allows you to edit bitmap versions of the outline glyphs you create above.
In the background is a small rendition of the outline, and in the foreground are the bits of the image. You may make the program calculate which bits should be set by pressing the "Recalculate button", the results usually need to be tweaked by hand. In the upper left corner is a full sized image of your bitmap glyph.
The metrics view allows you to see how the glyphs look together.
You can change the width and left/right bearings of a glyph, either by dragging in the upper part of the window or by entering an appropriate number in the lower.
You can also provide kerning information for any two adjacent glyphs. You can view how various OpenType features affect the glyph stream
Note that in Hebrew, or Arabic (or any other right to left alphabet) the glyphs will start on the right and run to the left. While in CJK fonts you may want to see things arranged vertically.
-- Next --


This is the documentation for the Sphinx documentation builder. Sphinx is a tool that translates a set of reStructuredText source files into various output formats, automatically producing cross-references, indices etc.
The focus is on hand-written documentation, rather than auto-generated API docs. Though there is limited support for that kind of docs as well (which is intended to be freely mixed with hand-written content), if you need pure API docs have a look at Epydoc, which also understands reST.
Sphinx needs at least Python 2.4 to run. If you like to have source code highlighting support, you must also install the Pygments library, which you can do via setuptools’ easy_install. Sphinx should work with docutils version 0.4 or some (not broken) SVN trunk snapshot.
The root directory of a documentation collection is called the source directory. Normally, this directory also contains the Sphinx configuration file conf.py, but that file can also live in another directory, the configuration directory.
New in version 0.3: Support for a different configuration directory.
Sphinx comes with a script called sphinx-quickstart that sets up a source directory and creates a default conf.py from a few questions it asks you. Just run
$ sphinx-quickstart
and answer the questions.
A build is started with the sphinx-build script. It is called like this:
$ sphinx-build -b latex sourcedir builddir
where sourcedir is the source directory, and builddir is the directory in which you want to place the built documentation (it must be an existing directory). The -b option selects a builder; in this example Sphinx will build LaTeX files.
The sphinx-build script has several more options:
Don’t look for the conf.py in the source directory, but use the given configuration directory instead. Note that various other files and paths given by configuration values are expected to be relative to the configuration directory, so they will have to be present at this location too.
New in version 0.3.
You can also give one or more filenames on the command line after the source and build directories. Sphinx will then try to build only these output files (and their dependencies).


{% include 'header.html' %}
{% include 'menu.html' %} {% if external_js %} {% else %} {% endif %} {% if external_css %}
{% else %}
{% endif %}
{% include 'project/sidebar.html' %}
Create new issue
Info
Additional fields
Name:
Description:
Fix:
Services:
Add
URL path/service:
CVSS:
CVSS calculator
CVE:
CWE:
Status:
Select status
PoC creation
PoC available
Confirmed
Wasn't Confirmed
Pending...
Need to check
Need to recheck
Criticality:
Select criticality
use CVSS criticality
Information (cvss=0.0)
Low (cvss=2.0)
Medium (cvss=5.0)
High (cvss=8.0)
Critical (cvss=9.5)
Parameter:
Type:
Select type
Custom
Web
Credentials
Service
{% if errors is defined and errors %}
There were some errors with issue
{% for error in errors %}
{{ error }}
{% endfor %}
{% endif %} {% if errors is defined and not errors %}
Issue was added successfully!
{% endif %}
Text fields
Add field
Select field type
Text field
Number field
Float field
Boolean field
Add variable
File fields
Add field
Add variable
{% include 'footer.html' %}


-
#Trackr is a single page web application which enables users to track Twitter trends
geographically by viewing a data layer of tweet locations over a
Google Map.
The menu on the left hand side allows the user to filter tweets by hashtag, location and date.
The filtered tweets appear as markers on the Google Map and the radius region from the selected
location (if given) is displayed as a blue circle. By clicking one of the markers, information about the tweet is shown,
such as the tweet text, username and user profile picture.
Beneath the menu, statistics about the current search are shown, with two bar charts displaying the frequency of
different languages and origin countries in the tweets.
App Architecture
- The app follows the MVC (Model-View-Controller) design pattern,
ensuring that the model (MySQL database, with tweet data), the controller (Wildfly +
Hibernate server stack) and the view (HTML5, CSS and Javascript)
are separated and communicate via clear APIs.
The core HTML5 feature used is Canvas (to draw the selected areas
onto the map) and the app also make use of the geolocation
API, semantic markup, the history API and the new 'date' form input type.
- Back-end
The back-end's role is to receive AJAX requests from the client, request tweets from the Twitter API,
write these tweets to the database and return the tweets in JSON format to the client front-end.
The main servlet (the application controller) is the SearchServlet Java class, which delegates tasks
to the TwitterBuilder Java Class where the bulk of the tweet processing is carried out.
We use Wildfly 10.0 for the server with Hibernate (the persistence) and a MySQL database, with the back-end
code implemented in Java.
The full back-end Java docs are available here.
- Front-end
The front-end has been developed as a single-page interface and is designed to be responsive for a range of
screen sizes (optimised for desktop browsers and mobile phones). It has been implemented with
HTML5, CSS and Javascript using the Bootstrap framework.
HTML5. The HTML5 provides the web page structure, separating content into three parts: the menu (for entering
search criteria), the Google Maps layer, and the statistics charts.
CSS. The CSS provides the styling information for the web page. To achieve a modern, clear and clean
design, we utilise primarily standard Bootstrap CSS for forms, buttons and other user interface items, as
these are so commonplace on the Web that users expect a similar style on all web sites. We also added custom
CSS for certain elements, such as our charts.
JavaScript. The JavaScript code implements the client-side logic of the web app. To ensure the web page remains
responsive during searches, the app implements an asynchronous application model with AJAX for communication between the
client and server. The JS code validates the user's search input, sends an AJAX request to the server based on this input,
and processes the JSON response from the server. It also communicates with the Google Maps Javascript API to add tweet markers
to the map and for geocoding, and the CanvasLayer JS library is used to overlay the map with Canvas graphics (currently a blue
circle showing the search radius, with room to develop this further). JS also provides the majority of the UI functionality
(for example button functionality, charts, and address autocomplete).
Tweets are shown as blue markers. Clicking on a marker displays an infowindow with more information about the tweet, and the marker
color changes to yellow to indicate that it has been selected. The boundaries of the map and zoom level are adjusted for each search
to ensure the best possible view of the markers.
Web technologies used
- #trackr is a pure web application (no browser plug-ins)
which utilises the following web technologies:
Canvas. This is the core HTML5 technology used. A Canvas layer is placed over the Google map so that the search
radius can be displayed as a blue overlay. The search radius is determined by the location (the center of the circle)
and the radius entered by the user. The size of the circles can then be increased and decreased to visually explore
the locations included by different search radiuses. Multiple circles can be displayed and resized on the map at the same time.
Geolocation API. This HTML5 API is used to determine the user's location and enter it into the search location field.
Semantic markup. Semantic markup has been used in the HTML to make the structure of the web page clearer to those examining
the code. This improves readability for other developers but is most useful for automated parsing of the code, for example
so that text-to-speech software can determine which sections of a page are most important to the user.
SVG and D3.js We use the D3.js library to draw the two SVG charts (which show the languages and countries represented in the
tweet results).
AJAX. The client and server use AJAX to communicate. When the user presses Search, if their input is valid the client generates
an XMLHttpRequest which is sent to the server. The server queries the Twitter Search API and returns the tweet results as a JSON response.
Because this process is asynchronous, the page is still responsive whilst the request is in progress.
Google Maps Javascript API. This is used for address autocomplete in the search location field, to geocode tweet
locations reported by the Twitter Search API, and to add markers to the Google Map at the relevant locations. Each marker has
an associated Infowindow with the tweet data which is displayed when the marker is clicked on.
-
Twitter Search API. The server uses this API to request tweets matching the user's search criteria. Unfortunately, the free
version of the API is very limited (for example, only tweets from the last 7 days can be searched) and returns very poor quality
location information. Often location information is missing because the Twitter user has chosen not to enable geolocation for privacy reasons.
In such cases we attempt to fetch a location from the user's profile (their home city), but if this also fails then the tweet cannot be
plotted on the map. There are also cases where coordinates are returned but are clearly incorrect, for example a tweet about someone's day
shopping in London with coordinates in Antarctica. Erroneous coordinates from Antarctica were, bizarrely, so common that the client does not
plot these tweets on the map as there is a high probability the location is incorrect.
MySQL. #trackr uses a MySQL database to store the retrieved tweets. MySQL was chosen because it integrates well
with Hibernate. For simplicity the database schema closely corresponds to the structure of the JSON objects returned by the Twitter search API,
with separate tables for tweets, users, entities, coordinates and metadata. The intention of the database is to enable more advanced statistics,
data analysis (for example sentiment analysis of tweets and historical trend timelines), user profiles and query caching (to avoid reaching
API request limits) if the project was developed further. Because of the low number of tweets available with the free Twitter Search API,
database management is currently very straightforward and the storage requirements are low. However, if deploying this application publicly
and/or using one of the paid search APIs, this would require further development. Importantly, this detailed project documentation would
also not be made available to the public, because certain details (such as the exact structure of the database) could be used by hackers to exploit the system.
Discussion
-
Challenges: The back-end development was challenging as most of the team had no experience of back-end
web development. A great deal of time (>50hrs) was spent trying to resolve various database issues, including
incompatible character encodings (even with the character encoding set to utf8mb4 mySQL
could not store emoji on Windows, whereas this was possible on Linux - we found no solution for this other than workarounds for
Windows to remove emoji characters) and database session/connection management. We also found working with the Twitter Search API
quite challenging. It is not a complex API and is well documented, but does not appear to function as claimed in the documentation!
We were unable to resolve our issues with fetching tweets from specific locations, as the API continues to return tweets from far
outside of the specified location radius.
What went well: In comparison to the back-end, the front-end development was quite straightforward. Using Bootstrap and the Searchable
Map Template gave us an excellent base to develop from. The template was only used for the webpage layout, with the vast majority of Javascript
code written from scratch (for example the search input verification, reset button popup, project documentation overlay, graphs, AJAX requests and
JSON tweet processing). The CanvasLayer library from Google was an exception to this; handling the projection of graphics onto the map proved to be
quite complex and this library provides an elegant solution.


You have been banned by a site administrator.
Reason: {{mrcBanReason}}
Expires: {{mrcBanExpires}}
MRC branding. Like login template is over-ridable with my_


- Controls
- Start: Enter
- Select: Space
- L/R Triggers: RO
- L/R Shoulders: EP
- ABXY Buttons: HGYT
- DPad: Arrow keys
- Left joy/thumb: WASDX
- Right joy/thumb: IJKL,
- Controller Layout
- More Help
- Please note that these are just the bindings that are set, but actual keybindings may vary.
- Saves
- Save Game
- Export SRAM
- Import SRAM
- Autosave (5m)
- States
- Save State (F2)
- Load State (F3)
- Undo Save State
- Undo Load State
- Export State
- Import State
- Graphics
- Smooth Pixels
- Double Resolution
- Cheats
- How to apply a cheat code
- 1. Open the Menu
- 2. Scroll down
- 3. Click "Cheats"
- 4. Click "Add new cheat to bottom/top"
- 5. Click the new cheat that you just created
- 6. Click "Code"
- 7. Enter/paste the cheat code
- 8. When you are done, press enter
- 9. Click "Enabled" (Set to ON)
- 10. Go back to Cheats by clicking the bar on the top
- 11. Click "Apply Changes"
- 12. Exit the menu
- Console
- Menu
- Pause


R
- the return type of this visitor's methodsP
- the type of the additional parameter to this visitor's methods.public interface AnnotationValueVisitor<R,P>
boolean
values versus int
values. Classes
implementing this interface are used to operate on a value when the
type of that value is unknown at compile time. When a visitor is
passed to a value's accept
method,
the visitXYZ method applicable to that value is
invoked.
Classes implementing this interface may or may not throw a
NullPointerException
if the additional parameter p
is null
; see documentation of the implementing class for
details.
WARNING: It is possible that methods will be added to this interface to accommodate new, currently unknown, language structures added to future versions of the Java™ programming language. Therefore, visitor classes directly implementing this interface may be source incompatible with future versions of the platform. To avoid this source incompatibility, visitor implementations are encouraged to instead extend the appropriate abstract visitor class that implements this interface. However, an API should generally use this visitor interface as the type for parameters, return type, etc. rather than one of the abstract classes.
| Modifier and Type | Method and Description |
|---|---|
R |
visit(AnnotationValue av)
A convenience method equivalent to
v.visit(av, null) . |
R |
visit(AnnotationValue av,
P p)
Visits an annotation value.
|
R |
visitAnnotation(AnnotationMirror a,
P p)
Visits an annotation value in an annotation.
|
R |
visitArray(List<? extends AnnotationValue> vals,
P p)
Visits an array value in an annotation.
|
R |
visitBoolean(boolean b,
P p)
Visits a
boolean value in an annotation. |
R |
visitByte(byte b,
P p)
Visits a
byte value in an annotation. |
R |
visitChar(char c,
P p)
Visits a
char value in an annotation. |
R |
visitDouble(double d,
P p)
Visits a
double value in an annotation. |
R |
visitEnumConstant(VariableElement c,
P p)
Visits an
enum value in an annotation. |
R |
visitFloat(float f,
P p)
Visits a
float value in an annotation. |
R |
visitInt(int i,
P p)
Visits an
int value in an annotation. |
R |
visitLong(long i,
P p)
Visits a
long value in an annotation. |
R |
visitShort(short s,
P p)
Visits a
short value in an annotation. |
R |
visitString(String s,
P p)
Visits a string value in an annotation.
|
R |
visitType(TypeMirror t,
P p)
Visits a type value in an annotation.
|
R |
visitUnknown(AnnotationValue av,
P p)
Visits an unknown kind of annotation value.
|
R visit(AnnotationValue av, P p)
av
- the value to visitp
- a visitor-specified parameterR visit(AnnotationValue av)
v.visit(av, null)
.av
- the value to visitR visitBoolean(boolean b, P p)
boolean
value in an annotation.b
- the value being visitedp
- a visitor-specified parameterR visitByte(byte b, P p)
byte
value in an annotation.b
- the value being visitedp
- a visitor-specified parameterR visitChar(char c, P p)
char
value in an annotation.c
- the value being visitedp
- a visitor-specified parameterR visitDouble(double d, P p)
double
value in an annotation.d
- the value being visitedp
- a visitor-specified parameterR visitFloat(float f, P p)
float
value in an annotation.f
- the value being visitedp
- a visitor-specified parameterR visitInt(int i, P p)
int
value in an annotation.i
- the value being visitedp
- a visitor-specified parameterR visitLong(long i, P p)
long
value in an annotation.i
- the value being visitedp
- a visitor-specified parameterR visitShort(short s, P p)
short
value in an annotation.s
- the value being visitedp
- a visitor-specified parameterR visitString(String s, P p)
s
- the value being visitedp
- a visitor-specified parameterR visitType(TypeMirror t, P p)
t
- the value being visitedp
- a visitor-specified parameterR visitEnumConstant(VariableElement c, P p)
enum
value in an annotation.c
- the value being visitedp
- a visitor-specified parameterR visitAnnotation(AnnotationMirror a, P p)
a
- the value being visitedp
- a visitor-specified parameterR visitArray(List<? extends AnnotationValue> vals, P p)
vals
- the value being visitedp
- a visitor-specified parameterR visitUnknown(AnnotationValue av, P p)
av
- the unknown value being visitedp
- a visitor-specified parameterUnknownAnnotationValueException
- a visitor implementation may optionally throw this exception Submit a bug or feature
For further API reference and developer documentation, see Java SE Documentation. That documentation contains more detailed, developer-targeted descriptions, with conceptual overviews, definitions of terms, workarounds, and working code examples.
Copyright © 1993, 2015, Oracle and/or its affiliates. All rights reserved.


{{ post.title }} By {{ post.author }} | {{ post.createdAt | date:'MMM d yyyy' }} Edit Post Edit Comments


Black Friday is cool, but the black MacBook was cooler
Source: Stephen Hackett
What you need to know
- The black MacBook was awesome, back in the day.
- But you had to pay through the nose to get it.
- Now I need to find one.
Sure, you can buy current Mac portables in a few different colors but none of them look as cool as the black MacBook did, way back in the day. At a time where all other MacBooks were white, the black one really stood out. And then there was that glowing white Apple logo on the back. So good!
Apple fan/commentator/podcaster/historian/all around nice guy Stephen Hackett has shared a new video in which he shows off his own black MacBook – complete with cracked top casing as was so often the case with these things. And it's hitting me right in the nostalgia feels.
Don't miss out on today's newest and best Black Friday deals
Amazon's Fire Tablet is the one Black Friday purchase you NEED to make!
Sure, Apple charged more for the black MacBook even when you take the upgraded hard disk into account, and sure it still discolored badly when your fingers went anywhere near it. But damn, look how great it looked. It somehow managed to be a black notebook that looked cool. Yet somehow none of the aircraft carrier PC notebooks of the time managed it.
Strange, that.


Use the RSA Protected Configuration provider to encrypt sections of your configuration files. You can use Aspnet_regiis.exe tool to encrypt sensitive data, such as connection strings, held in the Web.config and Machine.config files.
Connection strings contain sensitive resource access credentials (e.g., a connection string for a SQL server resource includes a username and password.) Connection strings stored in plaintext are dangerous, because an attacker that can compromise a server will be able to read those connection strings. Even if a machine is not compromised, connection strings stored in plain text are accessible to administrators and any other users with sufficient privileges on the host machine and/or Windows domain.
Always encrypt connection strings. In a web farm environment, the RSA protected configuration provider is an effective way to encrypt and decrypt configuration file sections because it uses asymmetric encryption to encrypt and decrypt, meaning the keys can easily be exported and imported from server to server. If the application is no deployed to a web farm environment DPAPI will work as well as RSA for encrypting connection strings.
Use the following steps to encrypt sections of your configuration files:
Identify the configuration sections to be encrypted. Encrypting and decrypting data incurs performance overhead. To keep this overhead to a minimum, encrypt only the sections of your configuration file that store sensitive data. In this case, we are interested in encrypting the <connectionStrings> element of the Web.config file since that is where the database connection string will reside.
Choose the machine or user store. The DataProtectionConfigurationProvider supports machine-level and user-level stores for key storage. The choice of store depends largely on whether or not your application shares a server with other applications and whether or not sensitive data must be kept private for each application.
Encrypt your configuration file data. Use the RSA Provider to Encrypt a Connection String in Web.config in a Web Farm. To do this, you must create a custom RSA encryption key container and deploy the same key container on all servers in your Web farm. This won't work by default because the default RSA encryption key, "NetFrameworkConfigurationKey", is different for each computer.
Run the following command from a .NET command prompt to encrypt the connectionStrings section using the machine level store:
aspnet_regiis -pe "connectionStrings" -app "/MachineRSA"
A web application is running in a web farm environment. The application uses an SQL database instance and has sensitive data that should not be accessible to other applications on the same system. The Web.config file contains a connectionString section that the application uses to access the SQL database across all machines in the farm:
<connectionStrings>
<add name="MyLocalSQLServer"
connectionString="Initial Catalog=pubs;User Id=sa;Password=asdasd;
data source=localhost;Integrated Security=SSPI;"
providerName="System.Data.SqlClient"/>
</connectionStrings>
Unfortunately, anyone capable of reading the web.config file for the application is now able to see the database, the username, and the password for the database instance, and will be able to execute statements at the same level of privilege as the application.
The Web.config file for an application running in a web farm environment contains a connectionString section that the application uses to access the SQL database across all machines in the farm:
<connectionStrings>
<add name="MyLocalSQLServer"
connectionString="Initial Catalog=pubs;User Id=sa;Password=asdasd;
data source=localhost;Integrated Security=SSPI;"
providerName="System.Data.SqlClient"/>
</connectionStrings>
Use RSAProtectedConfigurationProvider with the machine key store to encrypt the connectionStrings section. Add and configure a protected configuration provider to use the machine key store and run the following command from to encrypt the connectionStrings:
aspnet_regiis -pe "connectionStrings" -app "/MachineRSA"
At this point the connection string has been encrypted, which can be verified by looking at the Web.config file. There is no need to decrypt the file by hand, since ASP.NET handles this transparently.
Adapted from Microsoft patterns & practices guidance.


| Match ID | Match Name |
|---|---|
| 1 | India vs West Indies - 3rd ODI |
| 2 | England vs South Africa - 2nd ODI |
| 3 | Sri Lanka vs Australia - 1st ODI |
| Match ID | Match Name | Match Time |
|---|---|---|
| 1 | Pakistan vs Bangladesh - 4th ODI | Today - 8pm IST |
| 2 | England vs South Africa - 3rd ODI | Tomorrow - 6am IST |
| 3 | Sri Lanka vs Australia - 2nd ODI | Tomorrow - 7pm IST |


--- layout: post authors: ["Greg Wilson"] title: "January 2015 Lab Meeting" date: 2015-01-12 time: "20:00:00" tags: ["Lab Meeting"] ---
We will hold our next online lab meeting at 11:00 and again at 19:00 Eastern time on Thursday, January 22, 2015. People who are standing for election will have a chance to talk about what they hope to do and to answer questions from other members, and we'll present updates on our finances and on our new workshop and lesson templates. If you're planning to attend, please add yourself to this Etherpad. We look forward to seeing you then.


This App uses Math Jax to render math formulas from plain ASCII Text, this can be your quick go to when writing math papers


syslog: type/provider for syslog files for Puppet
This module provides a new type/provider for Puppet to read and modify syslog config files using the Augeas configuration library.
The advantage of using Augeas over the default Puppet parsedfile
implementations is that Augeas will go to great lengths to preserve file
formatting and comments, while also failing safely when needed.
This provider will hide all of the Augeas commands etc., you don't need to know anything about Augeas to make use of it.
Requirements
Ensure both Augeas and ruby-augeas 0.3.0+ bindings are installed and working as normal.
See Puppet/Augeas pre-requisites.
Installing
On Puppet 2.7.14+, the module can be installed easily (documentation):
puppet module install herculesteam/augeasproviders_syslog
You may see an error similar to this on Puppet 2.x (#13858):
Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type `syslog` at ...
Ensure the module is present in your puppetmaster's own environment (it doesn't
have to use it) and that the master has pluginsync enabled. Run the agent on
the puppetmaster to cause the custom types to be synced to its local libdir
(puppet master --configprint libdir
) and then restart the puppetmaster so it
loads them.
Compatibility
Puppet versions
Minimum of Puppet 2.7.
Augeas versions
| Augeas Versions | 0.10.0 | 1.0.0 | 1.1.0 | 1.2.0 |
|---|---|---|---|---|
| PROVIDERS | ||||
| syslog (augeas) | yes | yes | yes | yes |
| syslog (rsyslog) | no | yes | yes | yes |
Documentation and examples
Type documentation can be generated with puppet doc -r type
or viewed on the
Puppet Forge page.
A syslog
provider handles basic syslog configs, while an rsyslog
provider
handles the extended rsyslog config (this requires Augeas 1.0.0).
manage entry
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "file",
action => "/var/log/test.log",
}
manage entry with no file sync
syslog { "cron.*":
ensure => present,
facility => "cron",
level => "*",
action_type => "file",
action => "/var/log/cron",
no_sync => true,
}
manage remote hostname entry
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "hostname",
action => "centralserver",
}
manage remote hostname entry with port and protocol
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "hostname",
action_port => "514",
action_protocol => "tcp",
action => "centralserver",
}
manage user destination entry
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "user",
action => "root",
}
manage program entry
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "program",
action => "/usr/bin/foo",
}
delete entry
syslog { "mail.*":
ensure => absent,
facility => "mail",
level => "*",
action_type => "file",
action => "/var/log/maillog",
}
manage entry in rsyslog
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "file",
action => "/var/log/test.log",
provider => "rsyslog",
}
manage entry in another syslog location
syslog { "my test":
ensure => present,
facility => "local2",
level => "*",
action_type => "file",
action => "/var/log/test.log",
target => "/etc/mysyslog.conf",
}
Issues
Please file any issues or suggestions on GitHub.


--- layout: defaultDL title: Index ---
If you are not redirected automatically, follow the link to download the latest Launcher release


Contact Us
For more information or if you have a specific question, you can contact us using one of the following methods. You will receive a response as soon as possible.
Company Address
4000 MacArthur, #350
Newport Beach, CA 92660
<EMAIL_ADDRESS>provider.support@ccapipa.com


Canvas
History
- was used by Apple in Safari and Dashboard in 2004
- in 2005 in version 1.8 of Gecko browsers
- in Opera in 2006
- part of the HTML 5 specification
How to use Canvas API
-
Create the canvas element
-
In JS, get your canvas element by using the id
const canvas = document.getElementById('myCanvas');
-
Use the canvas element to get the context
const ctx = canvas.getContext('2d');
- Use the context to draw
Fallback content
canvas.getContext(contextType)
- "2d"
- "webgl" (or "experimental-webgl")
- "webgl2"
- "bitmaprenderer"
Coordinate space
Rectangles
fillRect(x, y, width, height)
Draws a filled rectangle
strokeRect(x, y, width, height)
Draws a rectangular outline
clearRect(x, y, width, height)
Clears the specified rectangular area, making it fully transparent
Arcs
arc(x, y, radius, startAngle, endAngle, anticlockwise)
Draws an arc
arcTo(x1, y1, x2, y2, radius)
Draws an arc, connected to the previous point by a straight line
radians = (Math.PI/180)*degrees
Text
fillText(text, x, y [, maxWidth])
Fills a given text at the given (x,y) position
strokeText(text, x, y [, maxWidth])
Strokes a given text at the given (x,y) position
Text properties
- font = value
-
textAlign = value
value: start(default), end, left, right or center
-
textBaseline = value
value: top, hanging, middle, alphabetic(default), ideographic, bottom
-
direction = value
value:ltr, rtl, inherit(default)
ctx.font = '50px serif';
ctx.fillText('Hello world', 50, 90);
Properties: Color
fillStyle = color
strokeStyle = color
globalAlpha = transparencyValue
//create fill rect with opacity=0.5
ctx.fillStyle = 'rgb(255,0,0)';
ctx.globalAlpha = 0.1;
ctx.fillRect(10, 50, 50, 30);
//create stroke rect with stroke opacity=0.5
ctx.strokeStyle = 'rgba(100, 0, 0, 0.5)';
ctx.strokeRect(10, 90, 50, 30)
Gradients
createLinearGradient(x1, y1, x2, y2)
createRadialGradient(x1, y1, r1, x2, y2, r2)
gradient.addColorStop(position, color)
// Create gradient
var grd = ctx.createLinearGradient(0, 0, 200, 0);
grd.addColorStop(0, "red");
grd.addColorStop(1, "white");
// Fill with gradient
ctx.fillStyle = grd;
ctx.fillRect(10, 10, 150, 80);
Images
drawImage(image, x, y)
const image = document.getElementById('source');
image.addEventListener('load', e => {
ctx.drawImage(image, 33, 71, 104, 124, 21, 20, 87, 104);
});
Patterns
createPattern(image, type)
image - CanvasImageSource,
type - how to use the image (repeat, repeat-x, repeat-y, no-repeat)
Path
A path is a list of points, lines and shapes of different width and of different color
are connected and form a shape.
How to use path
-
Create the path
beginPath()
-
use drawing commands to draw into the path
moveTo(), lineTo(), arc(), arcTo(), rect() and etc
-
stroke or fill the path
stroke() - draws the shape by stroking its outline
fill() - draws a solid shape by filling the path's content area
- *
closePath() - adds a straight line
to the path, going to the start of the current sub-path
moveTo(x, y)
Moves the pen to the coordinates specified by x and y
lineTo(x, y)
Draws a line from the current drawing position to the position specified by x and y
rect(x, y, width, height)
Draws a rectangle whose top-left corner is specified by (x, y)
with the specified width and height
Clip
ctxC.fillStyle = 'white';
ctxC.fillRect(0,0,400,200);
ctxC.fillStyle = 'red';
ctxC.fillRect(0,0,400,100);
ctxC.beginPath();
//draw triangle
ctxC.closePath();
ctxC.lineWidth = 10;
ctxC.stroke();
ctxC.clip();
ctxC.fillStyle = 'yellow';
ctxC.fillRect(0,0,400,100);
Animation
- Clear the canvas
- Save the canvas state. Use save()
- Draw animated shapes, use requestAnimationFrame(callback)
- Restore the canvas state. Use restore()
What else?
- Shadows
- Transformations(translate, rotate, scale, transform)
- Pixel manipulation
- Manipulation with video data
- Image smoothing
- Hit regions and accessibility
- Using canvas in Webgl
Libraries and frameworks
- bHive.js
- PaperJS
- Fabric.js
- CreateJS
- PixiJS
- PhaserJS
- ...
Pixel manipulation
pros
- perfect for dealing with many elements
- pixel manipulations
- has no DOM => realy fast => great for games
- content can be updated at any time, new content can be drawn on old one
- has a similar result on all platforms
cons
- slow when drawing to large areas(high resolution)
- more complex than html&css
- does not scale well
- canvas content is not exposed to accessibility tools
- text elements are invisible to search engines


pi_mortality.Rd
The National Center for Health Statistics (NCHS) collects and disseminates the Nation's
official vital statistics. NCHS collects death certificate data from state vital
statistics offices for virtually all deaths occurring in the United States. Pneumonia
and influenza (P&I) deaths are identified based on ICD-10
multiple cause of death codes.
NCHS Mortality Surveillance System data are presented by the week the death occurred
at the national, state, and HHS Region levels. Data on the percentage of deaths due
to P&I on a national level are released two weeks after the week of death to allow
for collection of enough data to produce a stable percentage. States and HHS regions
with less than 20
reported by week during 2008-2012) will be marked as insufficient data. Collection
of complete data is not expected at the time of initial report, and a reliable
percentage of deaths due to P&I is not anticipated at the U.S. Department of Health
and Human Services region or state level within this two week period. The data for
earlier weeks are continually revised and the proportion of deaths due to P&I may
increase or decrease as new and updated death certificate data are received by NCHS.
The seasonal baseline of P&I deaths is calculated using a periodic regression model
that incorporates a robust regression procedure applied to data from the previous
five years. An increase of 1.645 standard deviations above the seasonal baseline
of P&I deaths is considered the "epidemic threshold," i.e., the point at which
the observed proportion of deaths attributed to pneumonia or influenza was
significantly higher than would be expected at that time of the year in the
absence of substantial influenza-related mortality. Baselines and thresholds are
calculated at the national and regional level and by age group.
pi_mortality(coverage_area = c("national", "state", "region"), years = NULL)
| coverage_area | coverage area for data (national, state or region) |
|---|---|
| years | a vector of years to retrieve data for (i.e. |
Queries for "state" and "region" are not necessarily as "instantaneous" as other API endpoints and can near or over 30s retrieval delays.
# NOT RUN { ndf <- pi_mortality() sdf <- pi_mortality("state") rdf <- pi_mortality("region") # }


ar3DCreateHandle.c File Reference
Include dependency graph for ar3DCreateHandle.c:
Functions | |
| AR3DHandle * | ar3DCreateHandle (const ARParam *arParam) |
| Create handle used for 3D calculation from calibrated camera parameters. More... | |
| AR3DHandle * | ar3DCreateHandle2 (const ARdouble cpara[3][4]) |
| Create handle used for 3D calculation from an intrinsic parameters matrix. More... | |
| int | ar3DDeleteHandle (AR3DHandle **handle) |
| Delete handle used for 3D calculation. More... | |
| int | ar3DChangeCpara (AR3DHandle *handle, const ARdouble cpara[3][4]) |
| (description) More... | |
| int | ar3DChangeMaxLoopCount (AR3DHandle *handle, int maxLoopCount) |
| (description) More... | |
| int | ar3DChangeLoopBreakThresh (AR3DHandle *handle, ARdouble loopBreakThresh) |
| (description) More... | |
| int | ar3DChangeLoopBreakThreshRatio (AR3DHandle *handle, ARdouble loopBreakThreshRatio) |
| (description) More... | |
| AR3DStereoHandle * | ar3DStereoCreateHandle (const ARParam *arParamL, const ARParam *arParamR, const ARdouble transL[3][4], const ARdouble transR[3][4]) |
| AR3DStereoHandle * | ar3DStereoCreateHandle2 (const ARdouble cparaL[3][4], const ARdouble cparaR[3][4], const ARdouble transL[3][4], const ARdouble transR[3][4]) |
| int | ar3DStereoDeleteHandle (AR3DStereoHandle **handle) |
| int | ar3DStereoChangeMaxLoopCount (AR3DStereoHandle *handle, int maxLoopCount) |
| int | ar3DStereoChangeLoopBreakThresh (AR3DStereoHandle *handle, ARdouble loopBreakThresh) |
| int | ar3DStereoChangeLoopBreakThreshRatio (AR3DStereoHandle *handle, ARdouble loopBreakThreshRatio) |
| int | ar3DStereoChangeCpara (AR3DStereoHandle *handle, ARdouble cparaL[3][4], ARdouble cparaR[3][4]) |
| int | ar3DStereoChangeTransMat (AR3DStereoHandle *handle, ARdouble transL[3][4], ARdouble transR[3][4]) |
Function Documentation
| int ar3DChangeCpara | ( | AR3DHandle * | handle, |
| const ARdouble | cpara[3][4] | ||
| ) |
(description)
(description)
- Parameters
-
handle (description) cpara (description)
- Returns
- (description)
Here is the call graph for this function:
| int ar3DChangeLoopBreakThresh | ( | AR3DHandle * | handle, |
| ARdouble | loopBreakThresh | ||
| ) |
(description)
(description)
- Parameters
-
handle (description) loopBreakThresh (description)
- Returns
- (description)
Here is the call graph for this function:
| int ar3DChangeLoopBreakThreshRatio | ( | AR3DHandle * | handle, |
| ARdouble | loopBreakThreshRatio | ||
| ) |
(description)
(description)
- Parameters
-
handle (description) loopBreakThreshRatio (description)
- Returns
- (description)
Here is the call graph for this function:
| int ar3DChangeMaxLoopCount | ( | AR3DHandle * | handle, |
| int | maxLoopCount | ||
| ) |
(description)
(description)
- Parameters
-
handle (description) maxLoopCount (description)
- Returns
- (description)
Here is the call graph for this function:
| AR3DHandle* ar3DCreateHandle | ( | const ARParam * | arParam | ) |
Create handle used for 3D calculation from calibrated camera parameters.
"3D calculation".
An AR3DHandle holds data structures used in calculating the 3D pose of a marker from the 2D location of its corners (i.e. pose estimation).
- Parameters
-
arParam (description)
- Returns
- The handle. When no more ar3D*() functions need be called, the handle should be deleted by calling ar3DDeleteHandle().
- See also
- ar3DCreateHandle2
- ar3DDeleteHandle
Here is the call graph for this function:
| AR3DHandle* ar3DCreateHandle2 | ( | const ARdouble | cpara[3][4] | ) |
Create handle used for 3D calculation from an intrinsic parameters matrix.
An AR3DHandle holds data structures used in calculating the 3D pose of a marker from the 2D location of its corners (i.e. pose estimation).
- Parameters
-
cpara (description)
- Returns
- The handle. When no more ar3D*() functions need be called, the handle should be deleted by calling ar3DDeleteHandle().
- See also
- ar3DCreateHandle
- ar3DDeleteHandle
Here is the call graph for this function:
| int ar3DDeleteHandle | ( | AR3DHandle ** | handle | ) |
Delete handle used for 3D calculation.
When no more ar3D*() functions need be called, the handle should be deleted by calling ar3DDeleteHandle().
- Parameters
-
handle A pointer to the 3D handle. On success, the contents of this location will be set to NULL.
- Returns
- 0 if the handle was successfully deleted, -1 otherwise.
- See also
- ar3DDeleteHandle
Here is the call graph for this function:
| int ar3DStereoChangeCpara | ( | AR3DStereoHandle * | handle, |
| ARdouble | cparaL[3][4], | ||
| ARdouble | cparaR[3][4] | ||
| ) |
Here is the call graph for this function:
| int ar3DStereoChangeLoopBreakThresh | ( | AR3DStereoHandle * | handle, |
| ARdouble | loopBreakThresh | ||
| ) |
Here is the call graph for this function:
| int ar3DStereoChangeLoopBreakThreshRatio | ( | AR3DStereoHandle * | handle, |
| ARdouble | loopBreakThreshRatio | ||
| ) |
Here is the call graph for this function:
| int ar3DStereoChangeMaxLoopCount | ( | AR3DStereoHandle * | handle, |
| int | maxLoopCount | ||
| ) |
Here is the call graph for this function:
| int ar3DStereoChangeTransMat | ( | AR3DStereoHandle * | handle, |
| ARdouble | transL[3][4], | ||
| ARdouble | transR[3][4] | ||
| ) |
Here is the call graph for this function:
| AR3DStereoHandle* ar3DStereoCreateHandle | ( | const ARParam * | arParamL, |
| const ARParam * | arParamR, | ||
| const ARdouble | transL[3][4], | ||
| const ARdouble | transR[3][4] | ||
| ) |
"3D calculation by Stereo".
Here is the call graph for this function:
| AR3DStereoHandle* ar3DStereoCreateHandle2 | ( | const ARdouble | cparaL[3][4], |
| const ARdouble | cparaR[3][4], | ||
| const ARdouble | transL[3][4], | ||
| const ARdouble | transR[3][4] | ||
| ) |
Here is the call graph for this function:
| int ar3DStereoDeleteHandle | ( | AR3DStereoHandle ** | handle | ) |
Here is the call graph for this function:


Patrick Logan reminded me of immediates, and how interesting they can get when you have 64 bits.
As a quick overview of an immediate -- typically an object in a dynamically-typed, reference-based language (like Python or Smalltalk) will be made up of a memory location. In memory you have information about the object type, instance variables, etc. So on every operation you get this pointer, find the location in memory, and do stuff.
With an immediate you put the entire object into the "pointer". To do this, you might reserve the high bit to signal that this is an immediate. If it's set, you have 31 bits left to encode the rest of the object -- more than enough for a significant set of integers, and potentially other objects (like True, False, and None). It gets exciting with 64 bits, because you now have 63 bits of information left, which gives a lot of room for storing different objects.
For instance, let's say you have a four-bit header for all Python references (which is enough to distinguish a string), and 30 bits to give the string's address (I have no idea how long addresses really have to be, but anyway...); that gives you 30 bits to do whatever you want with. You could store a hash value in there, which means that in many cases you could compare and use strings without going into the heap (memory) at all. You could store the string length (maybe only using some of the bits, and limited to strings under a certain length).
Immediates can generally only be used for immutable types, because an immediate isn't passed around by reference -- since the "reference" stores the object directly, it gets copied everytime it is re-references (e.g., by assigning it to a variable). This is fine for immutables, because multiple instances are indistinguishable from a single instance, but for mutable values it would cause problems.
Some of this can already be done with 32 bits -- this sort of optimization is (I believe) common in Smalltalk and Scheme interpreters, typically for encoding small integers. And I don't believe this is being done at all in the Python interpreter (though I don't know for sure -- someone can correct me in the comments if I'm wrong). Maybe something else for the thesis idea list
I'm pretty sure immediates would make the C code of Python pretty fugly (you'd have to catch them in all sorts of places), but it might be fun to try it out in something like PyPy
Someone tried to modify the C source to Python to use the least significant bit of a PyObect* and have immediate integers. It didn't make much difference to performance.
Maybe it was Jeff Epler? He's nuts enough to have tried something like this :-)
Also, note that not every architecture in the world is byte addressed (though this is less of an issue if you use high bits as tags, but then you need more control over how your address space is layed out than you get from C).
That's a good point. The AltiVec unit in the PPC is 128 bit aligned, it completely ignores the last four bits. malloc() on OS X is guaranteed to give 128 bit aligned pointers for this reason.
Don't forget Psyco. Psyco doesn't use tag bits, but it does "virtualize" objects as simpler datatypes.# Phillip J. Eby


STEP 2: Payment cancellation authorisation
Payment cancellation authorisation for user with no SCA methods
8. Continue payment cancellation authorisation with call to
PUT endpoint
9. Enter payment id you have got from
STEP 1 in the field
10. Insert into request body the following json:
{{ jsonData1 | json }}
Put in YOUR_USER_PASSWORD the password of the user you chose (you can view users and their information in TPP-UI).
11. Execute endpoint and get
8. Continue payment cancellation authorisation with call to
PUT endpoint
9. Enter payment id you have got from
STEP 1 in the field
10. Insert into request body the following json:
{{ jsonData1 | json }}
Put in YOUR_USER_PASSWORD the password of the user you chose (you can view users and their information in TPP-UI).
11. Execute endpoint and get
12. Execute this PUT endpoint again, but this time update request body: fill it with the following json:
{{ jsonData2 | json }}
User has only one SCA method, so test TAN
8. Continue payment cancellation authorisation with call to
PUT endpoint
9. Enter payment id you have got from
STEP 1 in the field
10. Insert into request body the following json:
{{ jsonData1 | json }}
Put in YOUR_USER_PASSWORD the password of the user you chose (you can view users and their information in TPP-UI).
11. Execute endpoint and get
12. Execute this PUT endpoint again, but this time update request body: fill it with the following json:
{{ jsonData3 | json }}
Put in placeholder YOUR_AUTHENTICATION_METHOD_ID any value of authenticationMethodId of your choice. The response should be 200.
13. Execute this PUT endpoint again, update request body: fill it with the following json:
{{ jsonData2 | json }}
User has only one SCA method, so test TAN


(Cmd + click for multiple)
May take a second after submitting... If not in Firefox, go to it and wait for CAPTCHA


copy_backward
|
|
| Category: algorithms |
Component type: function |
Prototype
template <class BidirectionalIterator1, class BidirectionalIterator2>
BidirectionalIterator2 copy_backward(BidirectionalIterator1 first,
BidirectionalIterator1 last,
BidirectionalIterator2 result);
Description
Copy_backward copies elements from the range [first, last) to the range
[result - (last - first), result) [1]. That is, it performs the
assignments *(result - 1) = *(last - 1), *(result - 2) = *(last - 2),
and so on. Generally, for every integer n from 0 to last - first,
copy_backward performs the assignment *(result - n - 1) = *(last - n - 1).
Assignments are performed from the end of the input sequence to the
beginning, i.e. in order of increasing n. [2]
The return value is result - (last - first)
Definition
Declared in algo.h. The implementation is in algobase.h.
Requirements on types
-
BidirectionalIterator1 and BidirectionalIterator2 are
models of BidirectionalIterator.
-
BidirectionalIterator1's value type is convertible to
BidirectionalIterator2's value type.
Preconditions
-
[first, last) is a valid range.
-
result is not an iterator within the range [first, last).
-
There is enough space to hold all of the elements being copied.
More formally, the requirement is that
[result - (last - first), result) is a valid range.
Complexity
Linear. Exactly last - first assignments are performed.
Example
vector<int> V(15);
iota(V.begin(), V.end(), 1);
copy_backward(V.begin(), V.begin() + 10, V.begin() + 15);
Notes
[1]
Result is an iterator that points to the end of the output
range. This is highly unusual: in all other STL algorithms that
denote an output range by a single iterator, that iterator points to
the beginning of the range.
[2]
The order of assignments matters in the case where the input and
output ranges overlap: copy_backward may not be used if result is
in the range [first, last). That is, it may not be used if the
end of the output range overlaps with the input range, but it may be
used if the beginning of the output range overlaps with the input
range; copy has opposite restrictions.
If the two ranges are completely nonoverlapping, of course, then
either algorithm may be used.
See also
copy, copy_n
Copyright © 1996 Silicon Graphics, Inc.
|


Slack SLA and Support
Slack has done a remarkable job keeping up with its fast growth, and that extends to how the company has implemented its customer support and SLA offerings. Generally speaking, Slack handles support exactly how you might think it would: the more money you pay, the higher level of support you get. In the Slack for Teams product, free plans get standard support, mid-tier plans get priority support, and the highest tier (called Plus) receives 24/7 support.
Companies that move up to Slack’s enterprise offering, which it calls Enterprise Grid, receive the same 24/7 support, as well as a “dedicated account and customer success team” and more personalized support options.
If there’s one thing Slack could do a better job of here, it’s explaining the differences between these support levels—something it does not do either on its pricing website or in its documentation. The assumption might be that anybody not paying for a high-tier plan won’t care too much about support, but there is nonetheless a lot of room for interpretation with “standard” and “priority,” compared with the specific guarantees at the Plus level.
Notably, Slack is also one of only a handful of prominent SaaS companies—outside giant ones like Microsoft, Google, Salesforce and SAP—to publicly share details about its SLA for application uptime. Slack offers a 99.99 percent uptime guarantee for Slack for Teams Plus customers and Slack Enterprise Grid customers. Slack handles service credits a little differently than many companies: instead offering a portion of the monthly subscription fee for each percent (or less) below the promised uptime, Slack credits customers 100 times the amount they paid during the time the service was down.
In theory, this would mean that a company paying for 100 users on the Plus plan would receive approximately $173.61 in credits for an hour of downtime. ($1,250 / 720 hours in a month = $1.736 per hour.) However, Slack doesn’t calculate uptime on an individual level, but rather based on what percentage of users were affected. As the company explains:
This means that the service credits added to your account may not match your exact experience: when only a small minority of workspaces are affected, the downtime will average to a lower number and you may receive less than you expected. On the other hand, it also means you’ll receive credits for significant outages even if your workspace felt no impact. If you feel like a particular case was not handled correctly, don’t hesitate to contact us: we aim to please.
That practice might result in some disgruntled users, but Slack is at least clear in its explanation of how these calculations work. Additionally, customers who feel like they’ve been burned especially hard can always contact Slack support and try to work out a more satisfying arrangement.
This was published on Jul. 3, 2018.
Content Contributors
Is a feature of your app EnterpriseReady?
We'd love to work with you to breakdown your implementation and share it with the EnterpriseReady community.


Hey !
Prof.


--- layout: post title: I am a ToolWindow date: '2008-10-28T02:55:00.001Z' tags: modified_time: '2008-10-28T02:55:46.184Z' thumbnail: http://lh4.ggpht.com/TheTechnologist/SQZ_L9kKq-I/AAAAAAAAADo/w8SgFNVEoxU/s72-c/black_tshirt_girls_FF_thumb%5B2%5D.jpg?imgmax=800 blogger_id: tag:blogger.com,1999:blog-4015568221071268916.post-1357556651663468132 comments: true blogger_orig_url: http://serialseb.blogspot.com/2008/10/i-am-toolwindow.html ---
For anyone that attended Glenn’s talk.


--- layout: default title: 404 ---
Requested resource is unavailable —
I can't seem to find the page you're looking for.
or drop a line to if you have any questions or comments.
Thanks.


Before Change
"client_seq_len": 100,
"num_client": 1
},
{
"max_seq_len": 20,
"batch_size_per_worker": [64, 128, 256, 512],
"client_batch_size": 2048,
"client_seq_len": 100,
"num_client": 1
},
{
"max_seq_len": 20,
"batch_size_per_worker": 128,
After Change
// sleep until server is ready
time.sleep(15)
all_clients = []
for _ in range(args.num_client):
bc = BenchmarkClient(args)
bc.start()
all_clients.append(bc)
for bc in all_clients:
bc.join()
cur_speed = args.client_batch_size / bc.avg_time
tprint("%s: %5d\t%.3f\t%d/s" % (var_name, var, bc.avg_time, int(cur_speed)))


Welcome to the Nanog75 Hackathon!
With a strong focus on operations and automation, hack your way through network provisioning and management using industry tools and APIs -from ZTP, YDK, Ansible, GNMI, Open/R to gRIBI APIs and more, phew! - it's time to bring your automation chops to the table!
Day0
Day1
Day2
Connect to your pods!