I'm making a multi-weight font from a Thin weight and a Heavy weight. The glyphs that were correctly interpolated look good, but the ones that weren't look jumbled and terrible. (I know it looks like Verdana, don't remind me)
I will provide the two fonts as raw .sfd files, and as .otf exports. Could you help me look into this bug?
Check the number of points, the position of the first point (you can set the first point with CTRL-1), and the direction of the path.
Interpolation becomes especially tricky when there are multiple paths (e.g. any character with an enclosed counter such as o or e) or when it contains multiple references (letters with diacritics, for instance). You need to match up not just the points in each path, but also the order of the different paths and the order of different references. You can reorder paths and references by cutting and re-pasting them; this will move them to the top of the stack.
Unfortunately, path and reference ordering are not displayed. You can number your points (View>Number Points>SVG) which helps somewhat with ordering paths, though lines vs curves get numbered differently, so numbering won't always match exactly even between glyphs that interpolate just fine; also, this numbering lasts only as long as that glyph window is open; and none of this tells you anything about the ordering of references. It's a pain.
I usually just start cutting and re-pasting and use a process of elimination until I get it right.
Make your contours compatible, ie. same number of points and same start points across masters.
I fixed the problem by pasting each path onto a new glyph, corresponding glyphs in the same order.
Related
I'm using FontForge. I'm modifying the lower case q to make a straight-stalked 9. The q has 2 logical parts, the stalk, and the 'c'. The 'c' is too big vertically. How can I scale it down vertically while keeping the vertical stroke widths the same (and not altering any of the horizontal dimensions)?
I'm a novice with FontForge, so please spell out your explanation and provide step-by-step instructions. Thanks for your help.
It sounds like you want to decrease the x-height of the 'q' without changing stroke widths.
Font-forge provides a built-in tool to achieve this: Element > Styles > Change X-Height. You might like to experiment with this, but in practice it gives you very little control over the results and I would rarely use it.
Instead I would achieve this by directly modifying the nodes of the paths.
First, I would ensure that InterpolateCPsOnMotion is enabled. Double-click the pointer tool in your toolbox to access this setting.
This will help ensure that curves scale correctly (rather than distort) as you move control points. Now, I would select the nodes at the top and sides of the bowl of the q:
and use the down arrow key to move them down about half the distance you wish to decrease the height by. Then I would deselect the nodes at the side of the bowl:
and lower the remaining nodes the rest of the distance:
You will need to check the resulting appearance and possibly make tweaks to get it perfect. Note that this or any scaling technique can subtly distort the axis of modulated strokes, which you may wish to correct.
This technique presupposes that nodes are sensibly placed at the vertical and horizontal extrema of the bowl, and that you don't have extra nodes between these extrema. If you are not in this happy situation, you can add extrema by ctrl-shift-x and you can remove surplus nodes by selecting them and ctrl-m. If you can't remove extra nodes without significantly changing the shape of the bowl, you'll just have to modify these nodes by eye.
Another point: you say you're working from a "c". I'm not sure whether you just mean the C-shape of the bowl of the q, or whether you mean you are copying the actual glyph 'c'. Note that it is rare that the bowl of a 'q' will have exactly the same shape and weight as a 'c'. Typically the stroke will be somewhat lighter to achieve the right visual grey, and especial care will be taken where it intersects the stem. Often the two shapes will differ substantially.
My question is essentially the same as this one but the given answer doesn't work for me.
Here is a sample rendering (source) with
compound=true;
overlap=scalexy;
splines=true;
layout=neato;
There is some unnecessary overlap in the edges but this isn't too bad, the main problem is all the wasted space.
I tried setting sep=-0.7; and here's what happens.
The spacing is much better but now there is some overlap with the nodes. I experimented with different overlap parameters and this is the only one which gives remotely acceptable results.
I tried changing to fdp layout and setting the spring constant attribute K globally but I just got stuff like this:
The source is all straightforward a--b--c sort of stuff, no fancy tricks.
What I want is for all edges to be shortened as much as possible (up to a minimum) provided that this adjustment doesn't introduce any new overlaps, which is where sep fails completely. That doesn't seem like it should be too hard for a layout engine to do. Is it possible with the graphviz suite? I don't mind changing rendering software, but I don't want to annotate the source on a per-node or per-edge basis.
My ideal result would be to minimize the deviation in edge length, considered one node at a time, i.e. each node would have edges of equal length apart from the necessary exceptions, but that's wishful thinking. The priority is to reduce the length of each edge with the constraint that this cannot introduce overlap.
I will accept partial solutions but they must be fully automatic and open source.
How can I do this? Thanks.
I found https://sites.google.com/site/kuabus/programming-by-hu/graphviz-test-tool, an interactive tool for parameterizing the many options and repeatedly rendering them. I went through the full list provided by the Java application, eventually ending up with this set of attributes:
overlap=false
maxiter=99999999
damping=9999999
voro_margin=.001
start=0.1
K=1
nodesep=999999999999
labelloc=c
defaultdist=9999999
size=20,20
sep=+1
normalize=99999999
labeljust=l
outputorder=nodesfirst
concentrate=true
mindist=2
fontsize=99999999
center=true
scale=.01
inputscale=99999999
levelsgap=9999999
epsilon=0.0001
I was not able to find a parameterization of neato that made producing the desired "moderately scaled" graph possible.
You should set
overlap = compress;
this should compress it at much as possible.
Try sep = +1; first, and then play with values between 0 and +1 to find the optimal setting for you.
I have a graph with 50 nodes and 68 edged (sorry cannot publish the whole picture, just a fragment). Found two reasonable presets (1 and 2):
digraph {
graph[
# 1. Less overlaps but less compact.
# This is the choice for now.
layout=neato; overlap=prism; overlap_scaling=-3.5;
# 2. More compact but some overlaps exist (may be adjusted by `sep`).
#layout=neato; overlap=voronoi; sep=-0.15;
# The following is common.
outputorder=nodesfirst, # Will always draw edges over nodes.
splines=curved;
]
node[fontname="Helvetica",];
node[shape=box;style="filled";penwidth="0.5";width=0;height=0;margin="0.05,0.05"];
edge[label=" ";color="#000080";penwidth="0.5";arrowhead="open";arrowsize="0.7";];
. . .
}
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Tool for generating railroad diagram used on json.org
SQLite has some awesome graphs showing the grammer of the language on their website, does anyone know how these are made?
Is there a tool for generating graphs from grammas?
This example looks a lot like a finite automaton -- i.e. the graph equivalent of a regular expression. If you can repesent your grammar to a RE (naturally, not all grammars will be representable as REs!), you can use the Kleene's theorem to translate it into a FA graph.
Note that the alphabet in question for the REs is not single letters, but words and tokens. In the above example, the corresponding RE looks like:
DELETE FROM qualified-table-name
(WHERE expr|()) /* "WHERE expr" is optional; the alternative branch is the empty expression "()" */
(
(ORDER BY ordering-term (, ordering-term)*|()) /* ", ordering-term" may be repeated */
LIMIT expr ((OFFSET|,) expr|()) /* can use "OFFSET" or "," */
|()
)
This translates into a FA very similar to your diagram. GraphViz will do a passable job of drawing it legibly.
However that's not quite the same as the original, is it? Presenting it nicely is the next challenge. I'd suggest taking the nested RE expressions and rendering them recursively, starting at the leaves.
For example, to render (WHERE expr|()):
Two alternate paths. Render each separately:
Render WHERE expr:
Render WHERE as box.
Then an arrow.
Then render expr as a box.
Render () as a single arrow.
Find the longest (the first one) and stretch the others to match it.
Create start and end nodes at each end.
Draw connecting edges from the start node to each subpart, then from each subpart to the end node.
Doing this graphically means keeping track of box sizes and positions, including invisible boxes. There is an invisible box round each subpart. There are three things to note about the recursive structure:
The size of a part depends on the sizes of its children.
The location of a subpart depends on the location of its parent.
Locations of everything (may) depend on the sizes of everything else.
This implies that you should first calculate the sizes of each part, starting at the bottom. Then, once you know the size of the root, you can start positioning the parts, top-down.
Internally Flash obviously keeps a list of the primitives drawn using Graphics so I wondered if you have many such primitives in a Sprite, can you re-position/remove/alter individual items rather than clear and re-draw everything? Or is this deeper into the bowels of Flash than you're allowed (or recommended) to go?
Drawing primitives aren't accessible to user code once they've been committed to the graphics context, but if you need fast drawing objects you should use shapes instead of sprites. Sprites are containers that can contain other sprites and graphics contexts, Shapes are objects with only graphics contexts and non interactive.
Sprite -> DisplayObjectContainer - > InteractiveObject -> DisplayObject
Shape -> DisplayObject
Unfortunately, it is impossible: Once the items are drawn, you can only modify the full shape, but not the drawing itself.
To give you more of an explanation, I googled about how Flash actually calculates display objects. Unfortunately, I couldn't find anything specific.
But I found enough to make an educated guess: [EDIT]: I found a very interesting PDF on the Anatomy of a Flash. It explains the rendering tree and how graphics objects are treated internally.
I know for a fact that all shape tweens created in the IDE are compiled into shape sequences (each frame is stored as a separate image). And it makes sense to do it that way: Each new frame of the movie must be calculated, all vector images are added to a tree, each rendered as bitmaps, combined and drawn as one final bit plane, in order to be displayed. So it is only logical to do every possible shape calculation at compile time, rather than at runtime.
Then again, a bitmap would store 32 bits of color information for every single pixel, while vectors are stored in simple values, storing x and y coordinates, line style, fill style, etc. Some vectors can be grouped, so that for more complex shapes, line and fill styles only have to be stored once, and only coordinates are necessary for the rest. Also, primitive shapes like circles and rectangles require less information than objects combined from many individual points and lines.
[EDIT]: The above mentioned PDF says this:
Both AS3 and AS3 DisplayObjects are
converted to SObjects internally.
SObjects have a character associated.
Based on the character type it has
different drawing methods, but it all
resumes to drawing fills with
different source of colors.
It would take a very, very complex vector shape to require more single pieces of information than its bitmap representation, provided it is larger than a few pixels in width and height. Therefore, keeping simple shapes as vector representations consumes considerably less memory than storing full bitmaps - and so it is logical not to do shape rendering at compile time, as well (except for complicated shapes - then the "cacheAsBitmap" property comes into play).
Consider what I've said about vectors, line style and fill style, etc. - sounds quite a lot like the sequence of commands we have to write when drawing in ActionScript, right? I would assume these commands are simply converted 1:1 into exactly the kind of vector representations I was talking about. This would make the compiler faster, the binaries smaller, and the handling of both the IDE shapes and the AS shapes exactly the same.
[EDIT]: Turns out I was not quite right on that:
Edge & Colors
LSObjects tree is traversed and a list of edges is created
Edges have colors associated
Strokes are converted to edges
Colors are sources of display data, eg. Bitmaps, Video, Solid fills,
Gradients
Rasterization
Edges are sorted and a color is calculated for each pixel – pixels are
touched only once
Presentation
After the main rasterizer is done painting, the memory buffer is
copied to the screen
Now imagine all of those vectors were freely editable:
The sequence of commands would no longer be final! What if you were to add, move or erase one at runtime? For example: Having a rectangle inside of a filled rectangle subtracts the inner shape from the outer shape. What if you moved one of the corner points to the outside? The result would be a completely different shape! Or if you added one point? You could not store the shape as a rectangle any longer, requiring 5 point items to draw the same thing that once had been one rect item. In short: All the groupings and memory optimizations would no longer work. And it would also slow down runtime graphics considerably. That's why it is only allowed to add new elements to the shape, but not to modify them once they are drawn. And why you have to clear and redraw your graphics, if you want existing shapes to change.
[EDIT]: You can always do complex stuff by doing the calculations yourself. I still believe it was a good decision not to integrate those into basic graphics functionality.
With Flash CS5, and the XFL file format, this data is now accessible as XML.
For my example, you could make a tile map composed of 'Graphic' items from a MovieClip with various frames being various tiles. Instantly you come to the problem of needing to access those inaccessible frame indexes from 'Shape' objects.
If you put them into a symbol (even one that is not exported), you can find it in a file in your LIBRARY folder (after saving as 'xfl'). It mirrors the Library contents.
<DOMSymbolItem xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://ns.adobe.com/xfl/2008/" name="Tileset_Level_Test" itemID="4e00fe7f-00000450" linkageExportForAS="true" linkageClassName="Tileset_Level_Test" sourceLibraryItemHRef="Symbol 1" lastModified="1308719656" lastUniqueIdentifier="3">
<timeline>
<DOMTimeline name="Tileset_Level_Test">
<layers>
<DOMLayer name="Layer 1" color="#4FFF4F" current="true" isSelected="true" autoNamed="false">
<frames>
<DOMFrame index="0" keyMode="9728">
<elements>
<DOMSymbolInstance libraryItemName="Tileset_Test" name="" symbolType="graphic" firstFrame="8" loop="play once">
<transformationPoint>
<Point/>
</transformationPoint>
</DOMSymbolInstance>
<DOMSymbolInstance libraryItemName="Tileset_Test" name="" symbolType="graphic" firstFrame="4" loop="play once">
<matrix>
<Matrix tx="48"/>
</matrix>
<transformationPoint>
<Point/>
</transformationPoint>
</DOMSymbolInstance>
... lots more...
</elements>
</DOMFrame>
</frames>
</DOMLayer>
</layers>
</DOMTimeline>
</timeline>
</DOMSymbolItem>
The XML looks quite complex, but you can process it down to something much simpler with the XML class, and (for instance) construct a collision mask from a MovieClip mirroring those frame indexes, and identify spawn points and other special classes of things. Or you might process the data and draw the whole map yourself, having only needed a way to build it visually. All you might really care about is tx,ty attributes in the Matrix (for where a tile is placed), and 'firstFrame' attribute in the 'DOMSymbolInstance' (for which tile).
Anyways, you could preprocess it with an AIR applet to make just the data you want, and then either poop out a .as file to include in the project, or simplified XML, or whatever you like. Or use whatever other tools/languages you prefer, and add that processing step to your build scripting.
The xfl file format is also handy for tracking down and fixing all manner of things which Flash is too broken/buggy/AFU to fix, such as leftover font references in obscure parts of parts of parts.... You can either fix them in the library, or literally delete the file of the offending part, or edit the XML by hand. Grep and sed and find and xargs are all your friends for these tasks. Especially for things like snapping all coordinates to integer values, or proper cell boundaries, since all of Flash 'snapping' is horribly broken, too. Piping XML files through sed can be quite hazardous to files that you have not backed up, but quite rewarding for evil people who know what they're up to, and use version control.
Well every DisplayObject has only one graphic reference. So if you want to move (or scale etc.) several graphic objects in one Sprite, I suggest you use the display tree as it was intended.
Just add several children (Sprites or MovieClips or ...) in one Sprite each being redrawn when necessary.
This is just a LARGE generalized question regarding rays (and/or line segments or edges etc) and their place in a software rendered 3d engine that is/not performing raytracing operations. I'm learning the basics and I'm the first to admit that I don't know much about this stuff so please be kind. :)
I wondered why a parameterized line is not used instead of a ray(or are they??). I have looked around at a few cpp files around the internet and seen a couple of resources define a Ray.cpp object, one with a vertex and a vector, another used a point and a vector. I'm pretty sure that you can define an infinate line with only a normal or a vector and then define intersecting points along that line to create a line segment as a subset of that infinate line. Are there any current engines implementing lines in this way, or is there a better way to go about this?
To add further complication (or simplicity?) Wikipedia says that in vector space, the end points of a line segment are often vectors, notably u -> u + v, which makes alot of sence if defining a line by vectors in space rather than intersecting an already defined, infinate line, but I cannot find any implementation of this either which makes me wonder about the validity of my thoughts when applying this in a 3d engine and even further complication is created when looking at the Flash 3D engine, Papervision, I looked at the Ray class and it takes 6 individual number values as it's parameters and then returns them as 2 different Number3D, (the Papervision equivalent of a Vector), data types?!?
I'd be very interested to see an implementation of something which actually uses the CORRECT way of implementing these low level parts as per their true definitions.
I'm pretty sure that you can define an infinate line with only a normal or a vector
No, you can't. A vector would define a direction of the line, but all the parallel lines share the same direction, so to pick one, you need to pin it down using a specific point that the line passes through.
Lines are typically defined in Origin + Direction*K form, where K would take any real value, because that form is easy for other math. You could as well use two points on the line.