< theÉÍÍ»ÉÍÍ»É É º Ó¶ Ó¶ º Û º º º ÉÍÍÍ» ÌÍ ÉÍÍÍ»É ÉÍÍÍ»º É ÉÍÍÍ»É ÉÍÍÍ»É ÖÄ· ÉÍÍÍ»É ÉÍ»ÉÍ»É º º º º º º º Ó¶ º Ó¶ º º Ó¶ º Ó¶ ºÖ½ º Ó¶ º Ó¶ Ó¶ º º ºÚ×ÄÄĽ º Ú¶ ºÚ¶ º ºÚ¶ ºÚ¶ º ºº Ú¶ º º º º º º º³º ÖĶ ³º Ö¶³º Ö¶ º³º Ö¶³º Ö¶ ºº ³º Ö¶ º º º ½ Ð ÓÙÈÍÍͼ È;ÈÍÍͼÓÙÈÍÍͼÓÄÐÙÈÍÍͼÓÙÈÍÍͼºÚ½ÓÄÙÈÍÍͼÓĽ Ð º ÖÄÄÄÄ×Ù º ÖÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÈÍÍÍͼÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄĽ ÓÄÄÄ architecture (kernel) SNAV - main documentation - 11.8.90 page 1 - ÚÄÄÄÄÄÄÄ¿ ÄÄÄÄÄÄÄÄÄ>³ AVNER ³ ÄÄÄÄÄÄÄÄÄ>³ BEN ³ÄÄÄÄÄÄ> Software Engineering Method ÀÄÄÄÄÄÄÄÙ 10 Dov-Hoz st. Tel-Aviv 63416 Israel tel. 972-3-221535 ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ "The Screen NAVigator" ³ ³ ³ ³ THE C++ IMPLEMENTATION ³ ³ Technical specification ³ ³ ³ ³ Version 1.21, August 1990. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Copyright (c) 1990 by Avner Ben. Written by Avner Ben 11 August 1990. Original written 28 November 1989. SNAV - main documentation - 11.8.90 page 2 - ECONTENTSF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Contents ..................................................2 Preface ...................................................3 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Technical notes ...........................................4 Compatibility and future plans ............................5 Methodology ...............................................6 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Snav0 - character geometry ................................7 Snav1 - the semigraphic alphabet .........................13 Snav2 - the generic panel ................................17 Snav3 - shape creation and recognition ...................22 SNAV - main documentation - 11.8.90 page 3 - EPREFACEF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The Screen NAVigator version 1.21 is implemented in 4 source-code files named "snav0" Through "snav3", accompanied by 3 header files named "snav0" Through "snav2". A make-file is supplied to compile these files and bind them into a library. The code was developed on an AT clone using Zortech C++ version 2.0 and Borland Int'l's TurboC++ v1.0, alternatingly. The distribution of the code to these 4 source files reflects a functional partitioning. Snav0 furnishes the most elementary level: a simple "geometry" of characters. It defines the basic objects and operators on which the whole of the system builds. Snav1 supplies the (semigraphic) "alphabet" object. The data-structure it defines allows the application to define semigraphic entities on the character level, and manipulate them in complete disregard to their machine-architecture, collating-sequence or console-device implementation. Snav2 defines the generic "panel" - a formatted output device. The "panel" is a abstract entity, containing a "hollow compartment" (pure virtual methods), which the user must fill-in with the particulars of the various devices he/she may be manipulating in the real world. That is, one must use inheritance in order to enjou it. Snav3 defines the generic "shape" - an outline drawing using the semigraphic character set where available, (or course "typewriter graphics" (TWG) supplied by snav1). The "shape" class complex is supplied as a complete application, and is somewhat parametric. The user may exstend it either directly, or by inheritance. Future versions will be more parametric, so inheritance is not stressed. A complete, annotated listing of the classes, hidden data and enclosed methods is supplied in the three header files. The following documentation discusses the contents in nontechnical language. For a thorough study of the data structures involved and the logic behind their design, refer to file "article.prn". SNAV - main documentation - 11.8.90 page 4 - ETECHNICAL NOTESF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF The SNAV C++ implementation reflects many compromises in an attempt to ensure reasonable machine efficiency in an overall partitioning that is absolutely object-oriented. Compromises apply to method implementation and hidden data redundancy. SNAV does not involve garbage collection; it attempts not to produce it (references that cannot be deallocated), at the cost of data-structure overhead, common with such design policies. SNAV applications should have a good response time with fast 286 machines and above. On slow AT's and fast XT's a negligible delay may be apparent, compared with assembly-written drivers, but for most applications, it will be acceptable. On slow XT's and PC-G's a noticeable delay may (not at all cases) become apparent. For the last 4 years, I have been running my own character-graphic utilities, based on early versions of SNAV, on a number of 4.77Mhz XT's, and have survived the performance. The Object-Oriented paradigm does not compete procedural code in the field of performance. But it achieves superior performance in the field of software maintenance. The SNAV code is generic. Once you register your copy, you may easily improve it, to suit your application. For example, by replacing machine-sensitive portions with inline assembly, a practice enabled by most modern C compilers, or replacing the deafult character be character clear-screen with a memory-addressed method. Parameter passing and returning values, where objects are concerned, are made, as far as possible, by reference (rather than by value). This reflects the sad fact that, when temporary class instances have to be used (using the stack), different compilers pose different (and undocumented) limitations. Therefore, this legitimate feature of the language is too hazardous to use in software whose main concern is portability. As a rule, all functions that receive arguments by reference ("class &") do not change their arguments. In previous versions I have used the keyword "const" to clarify that, but I have given that practice up, because it creates more problems than it solves. Functions that receive an explicit pointer ("class *") may change their arguments. A null pointer argument may have different meanings (where permitted). The use of reference to return objects ("class & :: class func()") is a serious limitation, and requires some care from the user. These functions return reference to a static storage area, which is often within the object, and, on some delicate cases, within the function itself (common to all instances of the class). The programmer should avoid repeating the same class-operator more than once in the same expression, or the results may be undefined. "!a+!a" will not necessarily do what you may expect. SNAV - main documentation - 11.8.90 page 5 - ECOMPATIBILITY AND FUTURE PLANSF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Snav is part of the Metadiagram Architecture. Because the services these classes supply are so basic and universal, I have made all efforts to refrain from referring to any other module of the Metadiagram system in Snav. Snav is the only part of Metadiagram that may be used regardless of it, and is likely to remain that way. So far, my plans for expanding this module's capabilities, and my decisions as to compatibility with past versions reflect the requirements of the rest of the system, and are introduced to Snav, in the pace of that external development. At the moment, I am busy developing the first conversational front-end module of Metadiagram, which will be called "M-tree", generally, a "tree editor". The process affects foundation modules, some visible from the outside, like Snav, the "screen driver", and some yet to be published, like input-parser, user-interface manager, data-structure managers, system integration, etc.. User requirements, comments and objections have not yet affected Snav, at this early stage of its public exposure. When users begin to register their copies, they will naturally have a word in keeping their investment, or improving the product to fit their hidden requirements. But I naturally cannot - and must not - regard the opinions of people who think that software grows on trees, and that its authors should not be compensated for their effort. Specific notes concerning compatibility and future plans are to be found following specific class-structure descriptions. SNAV - main documentation - 11.8.90 page 6 - EMETHODOLOGYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Snav adheres to the object-oriented paradigm, in regard to information-hiding, and encapsulation. It makes intensive use of abstract datatyping, and some use of polymorphism. The use of inheritance is limited; there is no such thing as one semantic descent-tree to which all snav classes somehow fit, nor is such structure necessary. Unlike the OO "mainstream" which is concerned with co-ordinating processes, Snav is a data-driven application, managing data-structures. Which fits naturally with C++, where "class" is mere extension of the struct concept. Snav is a miniature in-memory database where iterator classes play as managers for data-aggregates, where the records are managed by lower-level classes. This is charted in the following specification by a private notation developed by me in the occasion of SNAV, called the Object-Dependency model. For syntax specification, refer to file "notation.prn". Snav classes abound with pointers, implementing a variety of linked-list structures. They make intensive use of constructors and destructors. They have copy constructors and copy assignment operators where these are needed. In addition, Snav uses some special methods, not explicitly supported by the C++ language. The method called "fix()" rebuilds controlled data-redundancy, fixes data-integrity, and structural "syntax errors". Fixers are invoked following some operation that may endanger data integrity. They cost the overhead of carrying all the tests, each time. The method called "normalize()" is a special fixer that reedits the data stored within the object, making some assumptions as to class "normal form". For example, understanding that the present color is in reverse-video. "spy constructors" copy their data-structure content "from the outside world", using some private "wisdom" in interpreting what they sense. For example, a shape that is created using cursor position, and traces whatever contour is recognizable, starting from that point. "Hooks" are methods that build interfaces for some abstract class for application in a device class. While hook methods do not violate data-hiding as far as C++ syntax is concerned, they do violate the wisdom invested in the design of the other class. Radical changes to the latter have to be reflected in the first, although no language construct explicitly binds them. This inelegant solution reflects the sad fact that designs have also to work, albeit the object-oriented paradigm not supporting there cause. The following documentation reflects only design decisions of importance, not every bit and byte that happens to be in the source code. For complete details refer to the header files which are fully prototyped and usually commented. For usage example, refer to the accompanying "demo" program. SNAV - main documentation - 11.8.90 page 7 - ESNAV0 - CHARACTER GEOMETRYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Object-dependency model of classes declared in file Snav0. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ ³ ³ d4³ d16³ ³d2 ³d16 ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÁÄÄÄ¿ ÚÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÁÄÄÄ¿ ³direction³ ³inter- ³ ÚÄ>³ axis ³ ³weight_d³ ÀÄÄÄÄÄÄÄÄÄÙ ³section³ ³ ÀÄÄÄÂÄÄÄÙ ÀÄÄÄÄÂÄÄÄÙ ÀÄÄÄÂÄÄÄÙ ³ ³ ³ ³ ³ ³ ³ ÚÄÄÄÄÄÁÄÄÄÄÄÄÙ ³ ³ ³ ³ ³ c4³ ³ d3³ ÚÄÄÄÄÁÄÄÄÄ¿ ³ ÚÄÄÄÄÁÄÄÄ¿ ³direction³ ÀÄÄÄÄÄÄ>³ axis/ ³ ÀÄÄÄÄÄÄÄÄÄÙ ³ weight ³ ÀÄÄÄÄÄÄÄÄÙ Compatibility. Snav0 is the oldest part of the SNAV system. its logic is deeply researched and is well tested. Modifications due are likely to expand its scope and affect mainly the hidden internals of classes. Such changes are not likely to affect referencing code seriously, though some minor changes are possible. The user is warned never to use explicit integer values when initializing or modifying objects, limit the explicit usage of enumerated values, and count as much as possible on system-supplied defaults. SNAV - main documentation E SNAV0 - CHARACTER GEOMETRYF - 11.8.90 page 8 - -1DIRECTION.-0 The datatype "direction" has a domain of five values, represented internally by an integer. It is really an enumerated type with methods. The values correspond to the four directions of the plane, and the null direction. Methods are supplied for obtaining the names of these values. By default, an object of class direction is initialized to "Right", weighing 1 (being the most common direction in European language texts). Operators are supplied for "incrementing" and "decrementing" the value to obtain a succession of directions (the order is predefined). This makes possible such typical loops as: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ for (direction dir; dir(); dir++) // dir() returns integer value ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The values are incremented in powers of 2, to allow for bitwise arithmetic, and set operations in the more complex datatype "intersection". The bitwise arithmetic makes the application somewhat less conceptual, but has proven to reduce response time of the demo program in about 10%, over ordinary multiplication and division. Note that direction and intersection method references are the most frequent operations in a SNAV application, and their optimal performance must overcome design elegance. For convenience, snav0 predefines five objects of type direction, supplying the whole domain, (intended to be read only). Compatibility. Future versions of SNAV may expand the direction domain to acknowledge directions of the dimension of depth. Also, a scheme may be introduced to allow the user to define his/her direction ordering. Neither of these changes is expected to affect present applications seriously. SNAV - main documentation E SNAV0 - CHARACTER GEOMETRYF - 11.8.90 page 9 - -1INTERSECTION.-0 The datatype "intersection" is a bitwise implementation for a "set of directions". Its domain includes 16 values. An object of class intersection may "include" (but not physically yield), at any moment of its existence, between zero and four distinct directions. The intersection does not physically allocate the set of directions for reasons of machine efficiency. Anyway, the need for that does not come up in practice. This typically results in loops such as this: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ // given is intersection avdir (available directions) ³ ³ for (direction dir; dir(); dir++) ³ ³ if avdir>=dir ... // direction is included ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Supplied are the necessary set-theoretic operators for inclusion, exclusion and their test, on both member and subset levels. Intersections are classified in "types", according to their internal organization, having functional significance in the semigraphic application, such as "corners", "forks", "arrowheads" etc. Methods for obtaining these types and their names are supplied. By default, an object of class intersection is initialized to all directions (type "cross"). Snav0 predefines a limited number of intersection objects, having to do with class "axis". Compatibility. All changes to the direction domain will naturally affect the intersection domain (being derived from it). SNAV - main documentation E SNAV0 - CHARACTER GEOMETRYF - 11.8.90 page 10 - -1AXIS.-0 "Axis" (or dimension) is a private case of intersection, including exactly two directions, that are held to be "opposite". Of the 16 intersections possible with the four directions of the plane, exactly 2 qualify for axis. These are called normally "horizontal" (weighing 1) and "vertical" (weighing 2), and sometimes "y" and "x". An obvious case for using an axis (rather than plain intersection or direction), is to measure the weight of a character. The need to generalize directions into an axis also arises when plotting or tracing an arc on the screen. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ // given is direction dir ³ ³ axis dim(dir); // allocates the axis on which dir is progressing ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Snav0 predefines objects for the axis domain, and the corresponding intersections. Compatibility. SNAV 1.20 implementation of axis assumes 2 dimensions, for machine efficiency. The addition of a third dimension may cause loss of performance, but no serious effect on current code. -1AXIS_WGT.-0 A technical datatype needed by weight_d. Stores the "weight" (line thickness) on an axis of the plane. Has no important methods, and is not normally referenced. -1WEIGHT_D.-0 The datatype "weight_d" (weight distribution) is the bridge between the abstract geometrical concepts defined so far and the more practical world of characters on the panel. It is also the first class dealt with so far, that internally allocates objects of another class, rather than a simple numeric code. An object of class weight distribution internally allocates a pair of axis/weight objects, storing the weight (line thickness), possibly of some character or class of characters, on each axis of the plane. (actually 3 of them, the first is ignored). Where characters are concerned, that obviously denotes the horizontal stroke and vertical stroke. In SNAV, Semigraphic characters are assumed to have an even weight distribution, and therefore, exactly two weights, one per axis. Obviously ,the combination of weight-distribution and intersection uniquely defines one semigraphic. for example: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ intersection avdir(RTDIR+LTDIR+DNDIR); // initialized by int value ³ ³ weight_d wgt(2,1); // initialized to double horizontal stroke ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ has the potential to yield the character Ñ (we still need an "alphabet" class to generate it - see snav1). SNAV - main documentation E SNAV0 - CHARACTER GEOMETRYF - 11.8.90 page 11 - Four weights are assumed arbitrarily (expressing the pc extended ASCII code-set): 1 and 2 denote the semigraphic subset of the pc (or other "newcode") alphabet. 3 ("full") is used for the full-pixel character. 0 is used for "TypeWriter Graphics" (TWG) - the characters + - | <> V^, but only when combined to create rudimentary charts. Snav0 predefines objects for pc-useful weight distributions. Compatibility. All changes to the number of axes supported will naturally affect the internal storage of weight distribution. Added arguments will default to support a two-dimensional system as subset. SNAV - main documentation - 11.8.90 page 12 - ESNAV0 - VERSION HISTORYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF 25.3.89 avner ben coded (in C). 28.7.89 avner ben - classified. snav v1.1: 5.3.90 avner ben - C++ v2.0 upgrade. 26.3.90 avner ben - removed some inline code to implementation. snav v1.2: 9.7.90 avner ben - tested under TurboC++. - renamed "next"/"prev" into "succ"/"pred". - removed "const" modifier from member function args. - reorganized comments. - fixed bug in weight_d constructor. - changed return by value to ref to static storage. - changed operator ~ to ! SNAV - main documentation - 11.8.90 page 13 - ESNAV1 - THE SEMIGRAPHIC ALPHABETF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Object-dependency model of classes declared in file Snav1. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³p* ÚÄÄÄÁÄÄÄÄ¿ ³computer³ ³alphabet³ ÀÄÄÄÂÄÄÄÄÙ ³ ÚÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ d*³ c16³ ÚÄÁÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ùùùùùùùùùùùùùù³char³ ùùù>³intersection³ ù ÀÄÂÄÄÙ ù ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ù ùùùùùùùùùù³ùùùùùùùùùù ³ ù ù ÚÄÄÄÄÄÄÁÄÄÄÄÄ¿ ³ ù ù c³ c³ c16³ ù ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÁÄÄÄÄ¿ ù ³intersection³ ³weight_d³ùùù>³weight_d³ ù ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÂÄÄÄÄÙ ù ³ ù ³ ù ³ ù ÚÄÁÄÄ¿ ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù>³char³ ÀÄÄÄÄÙ Compatibility. Any reference whatsoever to snav1 involves objects defined on snav0, so any change to the latter will affect it in the obvious way. Snav1 itself is a rather straightforward implementation of the general architecture needed to support a semigraphic alphabet on most current computers. A PC-oriented alphabet is supplied by default, which may be replaced or dynamically modified by the user. SNAV - main documentation E SNAV1 - THE SEMIGRAPHIC ALPHABETF - 11.8.90 page 14 - -1COMPUTER_ALPHABET.-0 An alphabet object consists of an array of weights and intersections (stored by integer value), where each pair defines the semigraphic qualities, if any, of the character bearing that number in the collating sequence in use. A method is supplied to "poke" values to the array, thus modifying the collating sequence during run-time. In addition, the alphabet constructor optionally takes a null-terminated integer array, specifying all the needed pokes in advance. The Constructor must receive the maximum number of characters to be used, including binary zero (256 in the pc example). This may not change. From this information, the alphabet allocates a cross-reference table, allowing fast retrieval of characters by semigraphic attributes, which is the main purpose of the SNAV system. The reference table is updated in real-time, reflecting any modification to the collating sequence. For example, a method is supplied for "inverting" the whole alphabet on a selected axis, for uses such as migrating from English to Hebrew in the middle of a sentence. Note that SNAV expects semigraphic-to-character assignments to be unique. No check is made to ensure that you do not assign the same attributes to two characters (by collating sequence number). The matching mechanism will come up with the match of lower ascii value, which may not always be what you may expect! The important alphabet methods deal with retrieval of characters from the present collating sequence, using separately prepared semigraphic attributes (weight and intersection), and with the opposite, querying the attributes of a given character. These methods may be combined to create continuous contour shapes, using semigraphics of various weights - see snav2. "Cdir" and "cweight" are low-level methods that retrieve character attributes. "Get_c" is a delicate mechanism for retrieving character by attributes. It tests a sequence of 6 search paths, from straightforward to less obvious alternatives, before it gives up (returning space). This mechanism is based upon long experience with live material. The user is warned not to modify it, unless in case of real emergency, because many higher level objects expect it to behave this way! "Translate" does the same working the specification from a sample character. SNAV - main documentation E SNAV1 - THE SEMIGRAPHIC ALPHABETF - 11.8.90 page 15 - Higher level methods deal with character "connectivity", where elements are considered two at a time. "Ccont" (Character CONTinues) tests if two characters connect in a given direction. it is the main primitive of semigraphic shape construction and recognition. "Carrw" (one Character in ARRoW) is a "hook" installed within the technical alphabet for panel::arclist, in the application world of shapes. Carrw suggests the next character in an "arc" (straight line), given its weight, general direction (In SNAV, everything is either moving in some direction or is not graphic), planned length, position and if it is pointed. The key argument is the "environment string", a type of argument used all over the system. This consists of five characters, number zero being the target character, and the other four its neighbors on the screen, their positions (1-4) determined by the order inherent in the direction datatype (obtained by direction::serial()). The user is warned not to use explicit integer values for constructing env. A typical method for constructing env is: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ // given position y:x on some screen, occupied by char c ³ ³ char env[6]; ³ ³ *env=c; ³ ³ for (direction dir; dir(); dir++) ³ ³ env[dir.serial()]=my_screen.get_neighbour(y,x,dir) ³ ³ env[5]='\0'; ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The method returns a character value to the user, who is then responsible for putting it in the desired place. "Cearrw" (carrw affecting Environment) is an extended version of carrw that "trims" inelegant "excess" of the neighbors, and makes some other nonlocal considerations. The user is expected to know where to put each of the elements in the string. Note that the method modifies its argument! Cearrw incurs a loss of response time, so make sure that you really need its improved esthetics. It is automatically used by the arc manager (snav2) if ENVMODIFY is #defined. Snav1 defines a default alphabet object, referenced by pointer. It includes an "in memory file" in the form of integer array, which it uses to initialize the object to the IBM-PC extended ASCII collating sequence. The user may then replace it with specific alphabet object(s), to suit the machine or application. Compatibility. Currently, the alphabet object has no facilities for generating its own character shapes, counting entirely on the host display device. This may force developers of pixel-oriented graphic software to extend the model to acknowledge their ability to generate their own characters. Future versions may include the ability to generate the semigraphic subset, possibly by downloading the definition to an external device, such as an EGA screen or printer. This may imply extensions to internal class architecture, and to the constructor. However, such modification is not expected to affect the methods concerned with character recognition and retrieval, using semigraphic attributes, (applying to most traffic to the alphabet object). SNAV - main documentation - 11.8.90 page 16 - ESNAV1 - VERSION HISTORYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF 28.7.89 avner ben coded. snav v1.0: 25.10.89 avner ben classified. snav v1.1: 5.3.90 avner ben - C++ v2.0 upgrade. - removed Zortech-specific strupr() - removed unnecessary #include to snav v1.2: 7.9.90 avner ben - tested under TurboC++. - removed "const" modifier from member function args. - added copy assignment and copy constructor. - changed return by value to ref to static storage. SNAV - main documentation - 11.8.90 page 17 - ESNAV2 - THE GENERIC PANELF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Object-dependency model of classes related to display management. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ p0³<ùùùùùùùùùùùùùùùùùùùùùù³p* ÚÄÄÁÄÄ¿ ÚÁ¿ ³panel³ ÚÄ>³?³ ÀÄÄÂÄÄÙ ³ ÀÄÙ ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄÄÄÄÄÂÄÄÄÄÙ ³ ³ d2³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÁÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ ³point_pos³ ³direction³ ³color³ ³square_pos³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÄÙ ³ ³ d2³ ÚÄÄÄÄÁÄÄÄÄ¿ ³point_pos³ ÀÄÄÄÄÄÄÄÄÄÙ Compatibility. "enframe" may be nested as long as there is space. Future versions will allow only one frame per panel, which will also serve as its title (if the box is titled). SNAV - main documentation E SNAV2 - THE GENERIC PANELF - 11.8.90 page 18 - -1PANEL.-0 An object of class panel may be any formatted output medium, wether static like a printed page or dynamic like a CRT screen, that can take characters, one at a time, so that each has a fixed position on the two axes of the plane, distributed evenly, like a matrix. This generic panel implementation does not support nonproportional spacing or varying font sizes. It is on a level definitely lower than the medium assumed by DTP software. The panel is assumed to be able to generate the appropriate character shape by its collating-sequence number, and retrieve the value of the character occupying each cell by y:x address, at any given moment. It is also supposed to manage colors (or visual "attributes") for these cells, in the same way. A snav panel is a "window", occupying an oblong slice of a larger display object, transparently managed by the hardware. Class "point_pos" is supplied to access cells on the panel. Window dimensions are specified by an object of class "square_pos", consisting of two points, for top-left and bottom-right corners. Also provided is struct "color_ind", grouping together visual attribute state variables. Color management follows the ANSI example. The attributes maintained are background color (enumerated on an 8 color scale), foreground color (same) and "attribute" (supporting high-intensity, reverse-video, blink, underline and invisible). A panel object manages a point_pos object for cursor position, a direction object for cursor direction, a color_ind object for visual attributes, and a square_pos object for (absolute) dimensions. Cursor addressing is done using absolute hardware-screen positions. There is no facility for interpreting cursor addressing, relative to window start. Since the abstract panel leaves physical cursor positioning and reading to the implementation, cursor addresses outside panel bounds should be ignored at character-print/read level, in the physical driver implementation, using the method "ask_legal". The cursor-direction object is used in for computing the next location, after a character "put" operation. By default, cursor direction is initialized to "Right" (actually, the value that direction() is initialized to). It may be changed during run-time, to acknowledge a Semitic or Asian language text, or for arc-processing. In each case, the cursor will behave accordingly (I am sure about the Semitic cursor. The "Asian" cursor is just a guess). Although the generic panel is expected to behave like a two-dimensional array, no assumption whatsoever is made as to its physical architecture. My private SNAV application works with half a dozen inherited screen types, one of them, a sparse matrix with variable length lines and unlimited size, used to edit pages for print, implemented by a host of pointers. Yet this formidable data structure answers the same methods as the simpleminded matrix CRT. The panel may be addressed either directly, or through the built-in cursor. If the point argument is NULL, cursor will be used and advanced. Cursor "wraps around" at the end of the line (and bottom of screen), if setup by "toggle_wrap". If a point is given, "direct cursor addressing" occurs, ignoring built-in cursor. Direction, if specified, overides the built-in direction. SNAV - main documentation E SNAV2 - THE GENERIC PANELF - 11.8.90 page 19 - The panel protocol consists of two levels. In the lower level are defined "virtual" methods, which are so device-specific that may never be defined to fit the general case. The second level offers "macros", of various complexity, taking the generic methods for granted. Because the use of polymorphism in C++ will not allow the user to refer to methods defined in the inherited class (and because the user must declare an inherited class, if he/she wants anything more than a heap of empty stubs), I have tried to include all nontrivial methods in the generic definition. However I did not include methods that assume a specific working procedure, such as newline. For a complete listing of the panel protocol, see snav2.hpp. For a sample implementation of a real-world device driver inheriting panel, see the sample application, demo1.hpp and demo1.cpp. The panel is designed to support some extra functions, preemting the needs of the rest of the system. The method "arclist" is a "hook" on the implementation side, for the "true" list method of the abstract object "arc". While this imports some functionality from within class arc, it ensures an absolutely device-independent drawing medium. The listing invokes the current alphabet's method "carrw" ("cearrw" if ENVMODIFY is #defined) - another hook - in order to elegantly "weld" each semigraphic element to its immediate environment, if that too is semigraphic. In order to understand what semigraphic "welding" is, experiment with the enclosed demo program, drawing one of the regular shapes supplied, and then crossing it with arcs of arbitrary weights. Another service supplied by the generic panel is "TWG" - TypeWriter Graphics conversion. The algorithm used (one of the only cases of long hard-to-follow code in the SNAV package) is a generalization of the line-oriented algorithm by that name, that I distributed in the PD in ordinary C, two years ago. Unlike the line-oriented version, the full-screen version can handle mixed TWG/semigraphic shapes, and is responsible for a somewhat more intelligent result (but is considerably slower, referring to the whole SNAV foundation). It does not account for the "fix" in line-oriented TWG, concerning open boxes. Twg's main function is to allow character-graphic charts to be transferrable to character sets that do not support real (connecting) semigraphic characters, such as most old ASCII 127 and EBCDIC "oldcode" implementations. It is also useful for fast-drawing semigraphic charts, if a few common-sense rules are observed. (e.g., all the drawings in this file have been prepared this way). Experiment with the TWG option in the enclosed demo. The shapes you experiment on must be charted using the 0:0 weight distribution! SNAV - main documentation E SNAV2 - THE GENERIC PANELF - 11.8.90 page 20 - Message passing scheme triggered by asking a panel to arclist. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄ¿ ÄÄarclistÄÄ>³panel³ÄÄcarrwÄÄ>³c.alphabet³ÄÄÂÄreplaceÄÂÄ>³weight_d³ ÀÂÄÄÄÄÙ ÀÂÄÄÄÄÄÄÄÄÄÙ ÃÄwidthÄÄÄ´ ÀÄÄÄÄÄÄÄÄÙ ÃÄ>env ÃÄ>cwidth ÃÄyÄÄÄÄÄÄÄ´ ÃÄ>put_c ÃÄ>get_c ÃÄxÄÄÄÄÄÄÄÙ ÃÄ>set_color ÃÄ>cdir ³ ÚÄÄÄÄ¿ ÀÄ>ask_color ÀÄ>ccont ÃÄoppositeÄÄ>³axis³ ³ ÀÄÄÄÄÙ ³ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ÃÄintsctsÄÂÄ>³intsction³ ÃÄunaryÄÄÄ´ ÀÄÄÄÄÄÄÄÄÄÙ ÃÄ () ÄÄÄÄ´ ÃÄ += ÄÄÄÄ´ ÃÄ -= ÄÄÄÄ´ ÃÄ = ÄÄÄÄ´ ÃÄ >= ÄÄÄÄÙ ³ ÚÄÄÄÄÄÄÄÄÄ¿ ÃÄoppostÄÄÂÄ>³direction³ ÃÄserialÄÄ´ ÀÄÄÄÄÄÄÄÄÄÙ ÃÄ () ÄÄÄÄ´ ÃÄ ! ÄÄÄÄ´ ÃÄ != ÄÄÄÄ´ ÀÄ ++ ÄÄÄÄÙ (see also class "shape" documentation, for origin of trigger) SNAV - main documentation - 11.8.90 page 21 - ESNAV2 - VERSION HISTORYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF 25.10.89 avner ben coded. snav v1.1: 22.1.90-11.4.90 avner ben: - C++ v2.0 upgrade - added "intelligent" curve appending mechanism. - added class square_pos - added color to panel - added default increment/decrement to class point - added last-curve pointer to shape - added offset from base to class curve, for use by shape iterator - added struct color_ind - added to class panel color and cursor processing - added to class panel language indicator and window - added to panel data redundancy with fix mechanism - changed some point functions to return void - changed some query-functions to return by value - debugged title centering in enframe - defined transparent screen-driver allocator - developed class point - in class curve, replaced offset with pendn toggle - moved iterator methods from curve to shape - moved some function from implementation screen driver - removed some inline code to implementation - removed special shapes to snav3 - renamed class curve stroke - renamed class point point_pos snav v1.2: 3.9.90 avner ben - tested under TurboC++. - removed "const" modifier from member function args. - renamed "next" into "succ" in some iterator classes. - renamed "next" into "move" in panel. - solved and debugged frame cleanup. - made destructor virtual. - removed start-point control from trace mechanism. - added the master-screen. snav v1.21. 11.9.90 avner ben: - removed shape-processing to snav3. - simplified screen enframing facility. SNAV - main documentation - 11.8.90 page 22 - ESNAV3 - SHAPE RECOGNITIONF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF Object-dependency model of classes related to shape drawing. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ p*³<ùùùùùùùùùù³p* ÚÄÄÁÄÄ¿ ÚÁ¿ ³shape³ ÚÄÄ>³?³ ÀÄÄÂÄÄÙ ³ ÀÄÙ ³ ³ ³ ÃÄÄÄÄÄÄÙ p0³<ùùùùùùùùùùùùù p*³ ÚÄÄÄÄÁÄÄÄÄ¿ ù ÚÄÄÄÁÄÄ¿ ³shape_seg³ ù ³stroke³ ÀÄÄÄÄÂÄÄÄÄÙ ù ÀÄÄÄÂÄÄÙ ³ ù ³ ÚÄÄÄÄÁÄÄÄÄÂÄÄÄÄÄ¿ ù ÚÄÄÄÁÄÄÄ¿ ³ d2³ ³ ù ³ ³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÁÄÄ¿ ³ ùùùÚÁ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ³direction³ ³color³ ÀÄÄÄÄ>³?³ ³point_pos³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÙ ÀÄÙ ÀÄÄÄÄÄÄÄÄÄÙ Compatibility. The generic "shape" owes to the SNAV approach, that contour shapes are charted by cursor in motion, and given the snav0 and snav1 arsenal of objects (direction, intersection, axis, weight_distribution, alphabet), and their operators. The snav shape differs radically from other graphic-package shapes, mainly in not being confined to a physical start position, and in being parametric, thus relying less on the traditional inheritance. Currently, the parametrization is in a preliminary state. However, enhancements to come will have little effect on the object's interface. SNAV - main documentation E SNAV3 - SHAPE RECOGNITIONF - 11.8.90 page 23 - -1SHAPE_SEGMENT-0 abstract base class "shape_segment" defines the genre of strait-line objects that may be used by the iterator class "shape" to draw semigraphic shapes. It includes some common attributes to all segment types - direction (in Snav, drawing is a fuction of motion) and color, and all the services such an object must supply, regardless of type (pure virtual fuctions). It also responds with some characteristics of itself, such as if it is of homogeneous structure. Other attributes, such as length cannot be answered from here. Unlike many pixel-oriented graphic packages, the origin point is not stored. Shape_segment is an abstract entity that may be listed starting at any given point, affecting whatever is logically implied on the following path. This concept may be demonstrated dramatically by experimenting with the "cut" and "paste" operations in the enclosed demo program. -1ARC.-0 Class "arc" is a straight-line subtype of shape-segment. It is capable of interfacing to "arclist" (a hook installed in class "panel"), for listing. Additional attributes peculiar to arc are length (the line itself is not stored), weight distribution (only the relevant axis considered during listing), and if it is pointed (the present version does not support double-tipped arrows). panel::arclist is responsible for "welding" the arc into the shapes it crosses. There are two levels of welding wisdom, depending wether arclist uses "carrw" or "cearrw" in class computer_alphabet (a lower-level hook). This may be controlled using the macro "ENVMODIFY" during compile-time. If a color is specified, it replaces the current screen color. Neighboring characters welded by cearrw calls are left in their own foreground color. In the present version, welding does not apply to color. Color is always replaced. -1DISPLAY STRING-0 class "display_string" is a character string subtype of "shape_segment". It stores only the string. Length is computed during run-time, and the other attributes (weight, pointedness etc.) do not apply. Some of the base class' services are implemented as empty stubs. Those pertaining to length truncate or space-pad the string (to the right). listing is made using panel::put_s. SNAV - main documentation E SNAV3 - SHAPE RECOGNITIONF - 11.8.90 page 24 - -1STROKE.-0 Class stroke is a linked-list member, intended to be managed by iterator class shape. It points to one abstract object of base class "shape_segment". Two derivatives of this abstract class are provided in the implementation: "arc" - for a continous semigraphic line, and "display_string". The user may overload additional, private segment types ("string" class, for example). Three constructors are supplied: one for a user-supplied shape_segment, and two, allocating objects of the predefined semantic hierarchy. A "pen-down" attribute allows suppressing the item's listing (but cursor is advanced). -1SHAPE.-0 Shape is a semi-generic entity, normally referenced by pointer. But, unlike the generic entity "panel", it contains primitives that are likely to be too simplistic for more regular or arbitrary shapes, and are therefore defined as "virtual" methods. Class shape's main role is to serve as iterator-class for class stroke. When a shape is created, it is initialized to either a user-supplied stroke-list, or to NULL. The user than "appends" strokes, be them individuals or chains, to the stroke-list. Append attempts to optimize the shape, by ignoring and/or unifying redundant strokes. The virtual methods "list" and "clear" scan the available stroke-list. Each arc listing proceeds from the exact point its predecessor stopped (to allow for "welding"). Discontinued shapes may be implemented by togglig pen up in specific strokes. A shape also responds with some information of its present "cursor" position (relative to its start), and can append pen-up moves to position this immaginary cursor relative to shape start or current position. It also computes its maximum size on both dimensions, and tells if a given point within will be overrun by a pen-down stroke. Compatibility. The current implementation of shape assumes it to be either chaotic or display a repeating pattern. Future releases may accommodate a shape that is made of subshapes. Soon to be introduced is some regular shape wisdom, through the procedural attributes of sequence (already implemented), repetition (presently implemented by inheritance) and (possibly) selection. This will be expressed by the addition of a "block" object, buffering between the shape and a group of strokes, and two services to begin and end the current block. The present interface will not be affected, because all traffic will be forwarded to the current block. SNAV - main documentation E SNAV3 - SHAPE RECOGNITIONF - 11.8.90 page 25 - Message passing scheme triggered by asking a shape to list. (selection between listing methods is implied by the polimorphic implementation of class "shape_segment" (an arc, a display_string, or user-supplied). ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ÚÄÄÄÄÄ¿ ÚÄÄÄÄÄÄ¿ ÚÄÄÄ¿ ÚÄÄÄÄÄ¿ ÄÄlistÄÄ>³shape³ÄÄlistÄÄ>³stroke³ÄÂÄlistÄÄ>³arc³ÄÄarclistÄÄ>³panel³ ÀÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ³ ÀÄÄÄÙ ÀÄÄÄÄÄÙ ³ ³ ÚÄÄÄ¿ ÚÄÄÄÄÄ¿ ÃÄlistÄÄ>³str³ÄÄput_sÄÄÄÄ>³panel³ ³ ÀÄÄÄÙ ÀÄÄÄÄÄÙ ³ ³ ÀÄlistÄÄ>(user-overloaded) (refer also to documentation for class panel) SNAV - main documentation E SNAV3 - SHAPE RECOGNITIONF - 11.8.90 page 26 - Object-dependency model of classes related to shape recognition. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ ³ ³ p*³<ùùùùùùùùùùùùùù³p* ÚÄÄÁÄÄ¿ ÚÄÄÄÁÄÄÄ¿ ³shape³ ÚÄÄ>³tracing³ ÀÄÄÂÄÄÙ ³ ÀÄÄÄÂÄÄÄÙ ³ ³ ³ ÚÄÄÄÄÁÄÄÄÄÄÄÄÙ ³ p*³ p*³ ÚÄÄÁÄÄÄ¿ ÚÄÄÄÁÄÄÄÄ¿ ³stroke³ ³landmark³ ÀÄÄÄÄÄÄÙ ÀÄÄÄÂÄÄÄÄÙ ³ ÚÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ³ d2³ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ³point_pos³ ³intersection³ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ Compatibility. At the present release, pattern recognition is of experimental status. The implementation calls for much optimization, and further research into its logic. It is supplied as a demonstration of the principle. No compatibility promised. Currently, The traced shape is graphic only. Future versions may include caption text recognition. SNAV - main documentation E SNAV3 - SHAPE RECOGNITIONF - 11.8.90 page 27 - -1TRACING.-0 The general derived shape "tracing" is a procedural entity whose function is to generate arbitrary shapes, presumably scanned from "the real world". The tracing constructor is a "spy constructor". its function may be defined as follows: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ If there exists in the real world (screen) in the coordinates ³ ³ specified (point) something that you may take for a shape, copy it ³ ³ as best as you can. You are free to use any method you know, and ³ ³ of-course, if you get caught (or hang the machine), we will deny ³ ³ any relationship with you. ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The additional data hidden in class tracing are technical, and are merely "working storage" for executing the scan, and have no significance once the constructor returns. Class tracing is the main primitive for applications involving semigraphic pattern recognition. For a typical application, see my ANSI editor "The Lecturer", where an early version of SNAV is used to automatically track semigraphic shapes on the screen, preserved for animation in the same scan order. Compatibility. The stroke-list built by an object of the current version "tracing" class, is highly unnormalized. It is a sequential scan (in direction() order), involving many unnecessary pen-jumps and broken lines. To demonstrate that, use the enclosed demo program to draw a fence-like shape all over the screen, then "cut" it, and then "paste" it, forcing your computer to its slowest speed. As you can see, the route the pen takes calls for optimization. Future releases may include tracing normalization and automatic recognition of some regular shapes. -1OBLONG.-0 Class oblong is supplied as an example for a "regular" shape. Since it is made of a repeating element with programmable underlying logic, only the essential pattern elements are stored in the shape. The complete shape is created during list-time by the overloaded lister. Oblong is also used by the "enframe" panel method in snav2. SNAV - main documentation - 11.8.90 page 28 - ESNAV3 - VERSION HISTORYF EÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄF snav v1.1: 13.3.90 avner ben: - separated from snav2 - debugged append_stroke of tracing - debugged oblong constructor - added clear to oblong - used pendn feature of curve instead of offset - fixed weight recording bug in first stroke - added color recording snav v1.2: 7.9.90 avner ben - tested under TurboC++ - cancelled start-point control in tracing mechanism snav v1.21. 11.9.90 avner ben: - added shape-processing from snav2. - added "shape_segment" as a generic shape member, with arc derived and a new "display_string" as derivatives. - added "display_box" shape. - added some navigation facility to shape.