A data structure is a set of data items like text strings or numbers conveniently organized for the target application, and that organization needs a set of syntactic rules. In the case of Lai4dCL the rules are given by Gosyx that stands for "good syntax" and is part of the Iquix framework. See the following sample data structure:

{ {type} {face} {vertices} { {{0}{0}{0}} {{0}{2}{0}} {{0}{2}{2}} } }

This data structure is a "face" entity definition in Lai4dCL. The simple elements, strings and numbers, appear enclosed by curly brackets. In return, elements can also be grouped in compound elements enclosing them in curly brackets. A compound element can be composed of other simple or compound elements what leads to a hierarchical structure. While the content of a simple element is a set of characters, the content of a compound element is a set of other elements and any character outside a simple element is ignored. These ignored characters are called interstitial characters and, although void of information, can be very useful to provide format to compound elements. They are normally white spaces like carriage returns, tabulators or spacers but any character can be an interstitial character. For example, the compound element “{{some data}{other data}}” can also be written as “{interstitial{some data}characters{other data}ignored}”; and the previous face entity can also be written without interstitial characters in a more compact way as “{{type}{face}{vertices}{{{0}{0}{0}}{{0}{2}{0}}{{0}{2}{2}}}}”. Interstitial characters could be used for commenting but there is a specific mechanism to do that. Any set of characters enclosed between number signs "#" will be ignored by the parser so this special character can be used for commenting purposes. As an example the element “{{some# data}{other# data}}” is equivalent to “{{some data}}”.

The curly brackets are special characters in Gosyx. Since special characters have a special meaning in Gosyx, there should be a way to codify such special characters when they are part of the definition of an element without the risk of confusion. The vertical bar is a special character that allows the inclusion of special characters in the internal definition of a simple element replacing them for their numeric code enclosed by vertical bars. Suppose a text string “ID{A-FGT}-Y”. It cannot be codified in Gosyx as “{ID{A-FGT}-Y}” because it generates a confusion. The correct way to codify that element in Gosyx is “{ID|123|A-FGT|125|-Y}”. The codes of the Gosyx special characters are: "{" 123, "}" 125, "|" 124, "#" 35. Indeed this mechanism permits the replacement of any character, special or not, by its numerical code.

The data structures used in Lai4dCL are called entities. An entity, like the previous face entity, is a map of unpacked key-value pairs, it is to say, the even elements (beginning at 0) are keys and the odd elements are values. The key elements are always simple elements while the value elements can be simple or compound. Each key-value pair is a member of the entity, therefore the given sample of a face entity has two members: "type" and "vertices". The order in which the members are provided in the entity is meaningless. For example, the face entity could also be written as “{{vertices}{{{0}{0}{0}}{{0}{2}{0}}{{0}{2}{2}}}{type}{face}}”.
The entity model of Lai4dCL defines a few standard members for its entities with special purposes:

• type: The name of the entity class. Its value is a simple element. All entities should define this member. If an entity does not define this member it will be considered a group entity.
• folder: The container for other entities. Its value is an element composed of other entities that are considered child entities. A folder member can be seen as a branch in the entity tree.
  
• name: An identifier that should be unique in the entity tree. Its value is a simple element. It is used for referencing purposes.
• inherit: Reference to an entity which members are to be inherited into this one. Its value is a simple element. Inheritance will be discussed later.
  

The root entity of a LAI4D drawing is a drawing entity whose type is "drawing" and whose folder member contains the entity definitions that build up the drawing. This root entity must be interpreted before the drawing can be rendered. The entity catalog of Lai4dCL defines a series of entity prototypes indicating what members can be used in each entity type and what their meaning is. Not all members of the prototype are mandatory for the entity and, in return, an entity can use members unrelated to its prototype which will be ignored during interpretation.

The inheritance strategy of Lai4dCL is a powerful characteristic that allows to easily define an entity or part of an entity from another one. In return, when an inherited entity is modified the heir entity inherits the changes. If an entity declares the "inherit" member then any member not directly declared in the entity can be inherited from the entity referenced in the "inherit" member. The value of the "inherit" member can be:

• The name of an entity. The search algorithm will begin the search in the root entity and will return the first occurrence of an entity in the entity tree with that name. This is absolute inheritance.
  
• A dot "." character. In this case the inherited entity is the parent entity regardless of whether it has a name or not. This is relative inheritance.

The only members that cannot be inherited are "inherit" and "name"; all other members, including "type" and "folder" can be inherited. If the inherited entity is the parent entity then the "folder" member is not inherited either.
See the following drawing sample that uses inheritance:

{ {type} {drawing} {folder} { { {type} {line} {vertices} { {{0}{0}} {{10}{10}} {{20}{0}} } {name} {a} } {{type}{curve}{inherit}{a}} } }

RENDERING RESULT

The drawing is composed by two entities:

1. A line defined by three vertices.
2. A curve defined by the same three vertices of the line.
   

The curve entity could also be written as “{{type}{curve}{vertices}{{{0}{0}}{{10}{10}}{{20}{0}}}}”. Instead of that, giving a name to the line entity allows to inherit its members and, then, the curve entity whose "inherit" member points to the entity named "a" can inherit the member "vertices" since it is not declared in the curve entity but it does in the line entity. In the other hand, the "type" member is declared in the curve entity so it cannot be inherited from the line entity. Since the name search algorithm begins the search in the root entity, the order in which the entities are defined is meaningless. The algorithm stops the search at the first match; the comparisons are case sensitive. Inheritance is recursive, this means that if the entity A inherits from the entity B and the entity B inherits from the entity C then the entity A can also inherit from C the members not directly declared in A or B. If the search algorithm does not found the entity referenced in the "inherit" member then nothing is inherited.
The following example illustrates the usage of absolute and relative inheritance:

{ {type} {drawing} {folder} { { {type} {} {line color} {{1}{0}{0}} {folder} { {{type}{curve}{inherit}{a}} { {type} {line} {vertices} { {{0}{0}} {{10}{10}} {{20}{0}} } {name} {a} {inherit} {.} } } } { {inherit} {a} {vertices} { {{0}{0}} {{20}{0}} } {line color} {{0}{0}{1}} } } }

RENDERING RESULT

In this case the drawing is composed by:

1. A group entity (the "type" member is an empty string, this member could have been omitted). It declares a "line color" member (red) and a "folder" member whose child entities are:
1. The already known curve entity that inherits from the entity named "a".
   
2. The already known line entity named "a" defined by three vertices. Now it also declares an "inherit" member whose value is a dot what means that it inherits from its parent entity, in this case the group entity.
   
2. An entity that does not declare a type but declares a "vertices" member, a "line color" member (blue) and inherits from the "a" entity.
   

The curve entity inherits from the "a" entity the "vertices" member; additionally it inherits the "line color" member of the group entity because the line entity named "a" inherits it from its parent which is the group entity. Therefore the curve entity and the line entity named "a" are painted in red. The last entity that does not declare an entity type inherits its "type" member from the entity named "a" so its type is "line". Since this entity declares its own members "vertices" and "line color" they are not inherited from the entity named "a", therefore its color is blue. Group entities are useful for defining common members to be inherited by its child entities.
While the usage of inheritance is simple, the edition of a drawing that exploits inheritance may present confusion so it shall be handled with care. Changes on inherited entities may lead to unexpected changes in heir entities or may break inheritance chains resulting in entity disappearing or even interpretation errors. The Lai4dCL inheritance strategy allows a good control over what is inherited since the user can select not only which entity to inherit from using the "inherit" member, but also which members must not be inherited declaring them in the heir entity, even with an empty value.

Once the concept of entity has been examined, it is important to differentiate the concept of node tree from the concept of entity tree. In any Gosyx structure the elements can be considered nodes of a tree because an element can have child elements. In a similar way, an entity can hold child entities within its folder member so this structure can be considered an entity tree. Any entity itself is a Gosyx structure, but not all Gosyx structures can be entities, only those structured as a set of unpacked key-value pairs can be. Therefore an entity tree is always a Gosyx node tree, but a node tree is not necessarily an entity tree.

A drawing is a tree structure of entities in which the root entity is of type "drawing". This means that the "drawing" entity contains the rest of entities. The most basic "drawing" entity only needs two members for indicating the type and the drawing content resulting in the prototype {{type}{drawing}{folder}{}}; the rest of entities are placed within the folder member. If necessary, the "drawing" entity can also have members for specifying the view definition or the background color as explained in the section "Standard entity set".

This is the set of entities intended for general use.

This is the set of entities intended for special purposes.

This section offers description and source code for several already done entities which can be of use due to their geometry or generation algorithm.

Several functions require various input steps in which the user could provide:

• A selection of graphic entities generated by double clicking over specific entities or by window capture for selecting a group of entities completely contained inside the window area. See the "Selection & visibility" section for more details.
• Texts or numbers typed in a text box. If the number entered is not an integer then the decimal separator shall be a dot.
• Point coordinates manually typed in a text box. LAI4D implements a parser that tries to understand the data structure entered by the user allowing a great flexibility in the input of coordinates. The user could enter "17.3,90,-10" or "17.3 90 -10" or "(17.3, 90, -10)" or even "{{17.3}{90}{-10}}" and the parser will correctly extract the three coordinates. At least one coordinate must be provided, the parser will automatically append zeroes up to complete three coordinates.
• One or more points selected on screen that can be singular points of entities, like vertices, or points located at the coordinated planes. When the mouse is close to a singular point of an entity its coordinates and a square mark are shown for highlighting that point and, if the user clicks inside the square, the point is selected. When the user clicks over a point that is not a singular point of an entity the selected point will be that placed at the coordinated plane (XY, XZ, YZ) which is more parallel to the viewport; therefore one of the three coordinates of the point will be 0. An exception to this behavior can be found in the function "Modify vertex".
  

When the function in progress requests a user's input, an input area is normally shown at the bottom of the viewport.

This input area can be composed of:

• A cancel button (): If pressed then the function is cancelled. Some commands are automatically recalled when done. This button finishes the loop and only cancels the last call.
• A pause button (℗/►): If pressed then the command is paused and the user can change the camera configuration in the usual way. Once the camera is configured the button can be pressed again in order to resume the command. This function is typically used while selecting points in the screen that are hidden for the current camera orientation.
• A delta button (∆): If pressed then the input of relative coordinates is enabled. In this situation the on-screen selection of points is ignored and the manually entered coordinates are treated as an offset with respect the last entered point.
• An angle button (<): If pressed then the input of polar coordinates is enabled. The order of the coordinates must be: radius, longitude, latitude (angles expressed in degrees). The coordinates left blank by the right will be replaced by 0. In this situation the on-screen selection of points is ignored. If this button is combined with the delta button then the manually entered coordinates are treated as an offset with respect the last entered point.
• A finish button (): It must be pressed when the user does not want to enter more input items in the current input step. For example it can be used for indicating the end of input when entering points for creating a polygonal line or for indicating the end of the entities selection step.
• A next step button (): It must be pressed for indicating that the current input step has finished and going into the next input step. It is typically used for passing the value typed in the text box to the function and going into the next step.
• A text box: It is used for manually input of numbers or coordinates. Most of the functions that require the input of points allow either the selection of points on screen or the manual input of coordinates. When the user types a value in the text box he must press the finish or next step button in order to pass that value to the function. If the value entered is not valid then the application warns the user with an alert message and returns to the previous input status.
  

Apart from those inputs requested by the invoked function, there are also other functions that offer in-place configurations. These functions or configurable commands can be found under the "Tools menu" and present their corresponding configurable options as child menu items of the corresponding function menu item. The big difference between the requested inputs and the in-place configurations is the fact that in-place configurations are preserved between function calls so they have to be edited only when necessary instead of having to be entered each time the function is invoked.

The basic management of the widget is carried out through a set of controls which are normally hidden until a user action generates an event. These controls are organized in hiddable groups placed at the corners of the widget. Additionally a long press event performed over an entity will raise a set of context tools with functions intended for that entity.

When a long press event occurs over a graphic entity a set of buttons with context tools is shown allowing to perform the following operations on that entity:

Through mouse wheel events the user can make a general exploration of the model space. Each event produces a combination of a zoom increment plus a camera movement. When the wheel is rolled up a zoom-in is performed while the camera is displaced towards the area pointed by the mouse. When the wheel is rolled down the zoom and camera displacement are inverse.
To use the dynamic zoom is a comfortable way of exploring a wide scenario without the need of calling several times to different camera configuration buttons.

 Undoes the last change in the drawing source and repaints the scene.

 Redoes the last undone change in the drawing source and repaints the scene.

 Opens the current drawing in design mode in a new window. If this function is invoked from design mode then the new window will show the drawing in its current state taking into account the possible changes performed.

 The tree explorer component allows to manage as a tree view the drawing or an entity. In design mode it also allows to edit the inspected element; the changes made in the element are committed only upon request through the corresponding button () at the title bar. LAI4D is transactional so this change is undoable pressing the "Undo" button in the tools menu. The button () allows to inspect the parent node of the currently shown node. The component does not retain the inspected element when it is hidden. Note that any node of the tree can be inspected in two different ways touching in the icon button just at the left of the node representation:

•  As a simple value (for single nodes) or as an expandable tree view (for compound nodes). This is the default inspection mode. When this is the active mode additional buttons are shown at the right of the node representation:
1.  Clear children: Only for compound nodes. Removes all child nodes from the current node.
2.  Append child: Appends a new child node at the bottom of the list of child nodes. If the current node is simple then it is converted into a compound node losing its simple value.
   
3. Insert before: Inserts a new node just before the current one modifying the list of child nodes of the parent node.
   
4.  Remove this: Removes the current node from the list of child nodes of the parent node. If the parent node loses all its children then it becomes into a simple node.
5. Focus this: Focus the view on the rendered entity owning this node. This function allows to find in the scene the entity this node pertains to. Not all nodes are child nodes of a rendered entity, particularly if the navigated entity is not the root of the drawing.
• As a text area showing the Gosyx source of the node serialized. This is a convenient mode for copying or pasting a complete data structure. The serialization mode can be changed with the configurable option "Gosyx serialization mode". See the "Gosyx" section for more details.

The full configuration of the view can be achieved through the use of the "view" entity. The functions described in this section cover the more commonly demanded view operations not available in the "On screen controls".

 Offers different storage and retrieval options.

 Allows to configure rendering and behavior options and parameters. Most of these options cannot be configured through the drawing source so they are offered for testing purposes in design mode.

 Contains all the functions intended to create or edit the drawing entities.

 Contains functions for extracting useful information from the existing entities.

 Miscellaneous utilities.

The common interface of the design assistant has the following elements: SEND button: Once the desired text or graphic input is ready to be processed the user must press the SEND button to pass the data to the design assistant in order to be analyzed. While the input is in progress the SEND button changes to a STOP button allowing to cancel the process. Input mode selector button: The mode can be  for text inputs or  for graphic inputs. When graphic input mode is active the sketch interpreter window is shown at the right. Clear message stack button: It can be used to delete all the messages returned by the assistant in past processes. Text input area: The user can type here the text to be processed in text input mode. Suggestion area: It is an area used by the assistant to show a short message with a hint or suggestion. Just below the suggestion area it is placed the message stack where the design assistant stores its responses. It is empty at the beginning and new responses are placed at the top of the stack. The current version of the design assistant only works on the client machine so the SEND button does not really send information to a remote server. That client-server working mode is foreseen for a future version.

The design assistant in text input mode can be used to find LAI4D entity prototypes whose type or member names approximately match the words entered in the text input area. In the sample image the user typed the word "poly". When the SEND button is pressed the assistant searches for approximated matches of the entered words in the internal catalog of entity prototypes. Each resulting match is displayed as a response in the message stack. The responses are sorted so as the most relevant one is placed at the top of the stack. In a similar way the design assistant can also be used to provide Gosyx format to an unstructured text. In the sample image the user typed a set of coordinates separated by spaces and distributed in lines, although other separators or distributions could have been used. When the SEND button is pressed the assistant tries to recognize a data structure in the passed text. It implements several generic parsing rules for identifying the data pieces and their hierarchical organization. This means that the assistant is able to understand different syntax which, in return, allows a great flexibility in the input. This function is very useful for generating the source code of an entity when the coordinates are to be manually typed or pasted from another format which uses a different syntax for structuring the data. All text responses have a "Copy to clipboard" ⧉ button at the right side of the response's header. Once copied, the response can be pasted into the source editor or a field of the Tree explorer.

The design assistant in graphic input mode can be used to interpret a sketch extracting a geometric entity. When the input mode selector button changes to graphic mode the "Sketch interpreter" tool is shown.

It is a minimalist drawing tool that allows to paint freehand strokes or to load a picture in the sketch area. Its UI has the following elements: Clear the sketch area. Undo the last drawing step, either a pencil or an eraser movement. Open a file picker dialog to load a picture in the sketch area. A picture can also be loaded through a drag & drop operation. Define a constrain window for the sketch analysis. Selector button for choosing between pencil  or eraser . The sketch interpreter of the design assistant is the face of the conceptualizer program JAIC. The goal of this program is to "imagine" the conceptual geometry represented by an imprecise raster image in a probabilistic way regardless of whether it is a recognizable shape or not. When analyzing an image, the objective of Jaic is to generate a formal geometry with "sense", either 2D or 3D, ready to be inserted as a LAI4D entity in the main drawing. "Sense" essentially means that Jaic tries to detect geometric concepts or some kind of regularity in the given image. When enough "sense" has been found Jaic generates a geometric hypothesis. In the sample image the user hand-drew the perspective of a shape in a paper sheet and then scanned it uploading the resulting picture to the sketch interpreter. When the SEND button is pressed the assistant analyzes the image of the sketch area and returns a set of hypothesis sorted by relevance in the message stack. By pressing the button the geometric entity of the corresponding hypothesis is passed to the design space. The design assistant tries to find the evident reference system of the 3D hypotheses but the insertion point of the entity is arbitrary. When the drawing is empty the program automatically performs a zoom extent so the just passed entity is immediately focused. In other case the user should manually find the entity. The input can be provided either by drawing a sketch directly with the sketch tool or by uploading a picture. But it must be clear that Jaic works with pixels, not strokes, regardless of whether the input comes from the sketch tool or from a picture. The sketch tool only paints black strokes over a white background although Jaic is capable of analyzing colors. Sharp images with not too small details, with homogeneous backgrounds and good contrast between strokes and background are better interpreted by Jaic. The program doesn't have a preference for a specific kind of 3D projection but, as it happens to humans, some projections offer more information about the represented geometry than others and, therefore, are easier to interpret.

The analysis carried out by Jaic could be described as an artificial imagination process since it begins with a single static image, normally representing an imprecise hand-made drawing, and without stereoscopic pictures, depth sensors or motion tracking to help in the analysis. Such a process can lead to more than one hypothesis, some of them 2D, others 3D, some of them very similar to that expected by the user, others too different. The user is in charge of selecting the best hypothesis, if any, for his purposes. See also the section "Design assistant options".

About the current version of JAIC
This version of Jaic is still very limited and only understands simple 2D or 3D polyhedral geometries not involving curves. If the user wants it, measures can be painted in the sketch in order to obtain geometries with specific dimensions. If no measures are provided (or recognized) then Jaic sizes the geometry according to the proportions extracted from the own sketch. Furthermore Jaic can speculate about hidden faces in some cases. These functions can be enabled or disabled from the configurations available at the section "Design assistant options". Not all functions are enabled by default.

Jaic implements a light OCR (Optical Character Recognition) specifically designed for recognizing numbers painted in the sketch. These numbers are intended to be measures of segments and can have decimal separators. Once recognized Jaic tries to link the measure to the painted segments basing the decision on proximity. If the linking is not possible then the measure is discarded. It is not necessary that all geometric elements have a measure. With the final set of geometries and measures Jaic tries to conveniently resize the different elements of the shape obtaining an hypothesis.
The success of the resizing depends on many factors and it is possible that only some of the measures get finally assigned to the corresponding geometry. 2D and 3D hypothesis are resolved using different algorithms and have different conditioning so the set of assigned measures may also be different. Indeed the provided set of measures can be compatible with 3D shapes and not with the corresponding 2D projection. For example, imagine the sketch of a regular tetrahedron in which the user paints the 6 measures for the 6 segments of the tetrahedron; it is obvious that the given set of measures is only compatible with the 3D hypothesis and not with the 2D one. It is also possible to provide measures geometrically incompatible as for example giving the lengths 10, 4, 3 to the segments of a triangle. In such cases some of the measures are automatically discarded by Jaic.

To increase the probability of success in the use of the sketch interpreter follow these hints:

• Simple and sharp images are interpreted faster and the geometries are better conceptualized by Jaic.
• A good contrast between the ink and paper will facilitate the extraction of the drawing elements.
• Avoid too big gaps when sketching lines.
• If a scanned picture presents sheet borders or graphic traces not related to the sketch then use a constrain window to restrict the analysis area.
• Avoid sketching partially hidden faces. Jaic is still unable to handle them and will only cause problems.
  
• If numbers are used then try to paint them clearly, the implemented OCR has its limits.
• The numbers must be horizontal and the digits composing a number should have similar size.
• Avoid too big or too small numbers. The height of a number must not be greater than 1/3 of the biggest side of the bounding-box of the sketch. In other case Jaic will consider it a geometric element instead of a number.
• The number must be close to the segment it is to be linked to, but not in direct contact, preferably with a separation of at least 1/2 the height of the number.
• It is preferable for the proportions between painted segments to be coherent with the painted measures. This is particularly convenient for the elements without assigned measure.
• Usually it is not necessary to provide all measures in a sketch, for example, two measures are enough for a rectangle. With more complex sketches try to concentrate all the provided measures in highly connected elements in order to facilitate the analysis.
  

The general features are explained through the next examples. The pictures shown as input can be used for testing purposes. Some of them have been drawn with the sketch tool and others have been scanned from a paper sheet. The analysis of raster images can be affected by the browser's zoom:

Input	Output	Comments
		A simple, clear and sharp image. In this case both 2D and 3D hypotheses have a clear sense.
		Jaic is good understanding tabular layouts, but many different connections between points may difficult the perfect alignment of segments.
		By default Jaic imagines the vertex of a pyramid closer to the observer than the base, as humans usually do.
		In general, regular polygons are easily detected in 3D hypothesis. As opposed to 2D hypothesis that work with segments, 3D hypothesis work with faces which allows other topological analysis.
		Another example of how clean sketches of simple geometries are well conceptualized by Jaic.
		The good contrast between ink and paper makes the scanned picture acceptable for analysis. Jaic tries to give sense to the 3D hypothesis using the available information.
		In this case the 3D hypothesis returned a regular pentagon, but poor sketches or blurred pictures are difficult to interpret.
		Despite the poor quality of the sketch, Jaic understood it as a cyclic geometry. This analysis is performed only for 3D hypotheses.
		Jaic correctly understood that the base of the prism was a regular hexagon. The poor image quality hindered the generation of a 2D hypothesis with more sense and this, in return, could lead to useless 3D hypothesis.
		This geometry is still simple enough to be conceptualized although resulting proportions between shape elements are not what they seem in the picture.
		Despite the low quality of the image the 3D hypothesis returned by Jaic has a lot of sense.
		The geometry is reasonably well interpreted but for the partially hidden face. Jaic does not implement knowledge to handle hidden faces yet.
		Jaic did what it could with this abstract geometry.
		In this version the holes of a face must be connected to the external face contour, either directly or through another hole already connected. Faces with holes can be handled this way.
		This is an example of how Jaic can work with colors. If this picture were edited and converted to grey scale it would become into a grey rectangle.
		Although the provided sketch is reasonably clear, the partially hidden face remains broken.
		Jaic tries to preserve the proportions of the provided segments when they don't have assigned measures.
		With those measures the orientation of segments cannot be preserved.
		The measures were correctly understood but they only have sense for a 3D hypothesis. Indeed the 2D hypothesis shows one of the tetrahedron's sides, not its base.
		Jaic accepts decimal separators placed at the bottom or at the top of the number. The size of a separator should not be greater than half of the number's height. All numbers were correctly recognized but the perspective of the 3D hypothesis hides two of them.

This section explains how to provide the initial configuration and the initial drawing source for a LAI4D widget. This initializing data is called the start-up instructions and to know how to handle them is important for sharing or publishing a LAI4D drawing. The start-up instructions are currently provided through the URL data (a.k.a. URL query srting) that is the last part of the URL after the path of the HTML file. If no start-up instructions are provided then a default configuration is used and an empty drawing is shown. The following data items can be specified in the start-up instructions although none of them is mandatory:

• The drawing source: If not specified then an empty drawing is shown. There are several options for indicating this item.
• The initial view configuration: If not specified then the default view defined by the loaded drawing, if any, will be used.
  
• The widget size: Is a pair of values with the width and height of the rectangular window area expressed in pixels that the widget should occupy. If not provided then all the window available area is occupied. This instruction is only considered in reader mode. Indicating the size of the widget in the start-up instructions is rarely necessary because, when the widget is embedded in an IFRAME element is this element in charge of specifying the size, and when the widget is displayed in a dedicated web page the size is not important.
• Different widget behaviors such as those related to the initial arrangement of the "on screen controls".
• The non-standard functionality to be loaded into the widget: The look and behavior of the LAI4D widget can be changed in order to add new functions for specific types of designs or according to customer requirements.
  

The start-up instructions are encapsulated in a data structure codified as a Gosyx entity. See the "Lai4dCL" section for more details about Gosyx entities. This initializing entity can have the following optional members:

• source: Is directly the drawing source. The value of the member contains one or more LAI4D entities. It can be a canonical or a non-canonical source as explained in the section "Edit source". It must be clear that the value of this member is not an entity but a container of entities.
• file: Its value indicates where to find the drawing source. This value can be simple or compound:
• If simple then it is considered a string with the URL of a text file from which to retrieve the drawing source and works in the same way as the URL of any other HTML resource such as images or CSS style sheets. The URL can point to any domain and can be any of the types accepted by the browser such as "http" or "ftp". Relative URLs are relative with respect the LAI4D HTML file. LAI4D drawings are stored by default UTF8 encoded with the ".L4D" file extension but the real file extension used is not relevant.
• If compound then it contains the necessary information for retrieving a drawing source from a hosting system that requires a specific communication protocol (a remote server for instance). The first element identifies the option and these are the available possibilities:
• lai4d: The file is retrieved from the LAI4D server requiring only the desired file name. The value node of this "file" member has the prototype {{lai4d}{file name}}. The file should have been previously saved with the function "Save server file". This option only works when the LAI4D widget has been loaded directly from the LAI4D official site.
• browser: The drawing source is retrieved from the browser's storage requiring the corresponding item key. The value node of this "file" member has the prototype {{browser}{item key}}. This option is intended for loading dynamically generated drawing sources through JavaScript in licensed LAI4D custom modules and it is disabled in the current version of the standard LAI4D widget.
  
• view: The value of this member is a "view" entity that will be passed to the "view" member of the drawing entity (replacing any previous value) so it will become the initial view configuration.
  
• append: The value of this member contains one or more LAI4D entities that are going to be appended to the "folder" member of the main drawing before it is interpreted. The "append" member is intended to let the user to modify the drawing source from the URL start-up instructions. Possible usages of the "append" member could be to include customized entities or to add a named entity which will be inherited by others. It must be clear that the value of this member is not an entity but a container of entities.
• size: Is a pair of values with the width and height of the LAI4D widget in pixels. If the indicated size is greater than the available window area then scroll bars will be shown.
• flags: This member is intended to contain a set of keywords whose mere presence indicates a configuration to be used when the widget is loaded. It works both in reader and design modes but it has no practical use in the last one. If the concurrency of several flags generates a conflict then the following flag order is used as a priority selector. These are the currently supported keywords and their meaning:
• controls fixed: The "on screen controls" are always shown.
• controls hidden: The "on screen controls" are always hidden.
• camera fixed: The camera configuration cannot be modified through screen events.
  
• modules: Its value identifies the non-standard functionality that must be loaded into the widget. This option is intended for loading licensed LAI4D custom modules.
  

In the strange case that more than one member for retrieving the drawing source is provided, the priority order is: source, file. As any other Gosyx structure, the initializing entity is parsed and this process could generate errors if it is badly written. The "Share" function is the easiest way for generating the URL with the main start-up instructions.

Here is an example of a complete URL with start-up instructions. In this case the LAI4D widget is in reader mode. The "size" member is provided. The "source" member indicates a canonical drawing source because it directly contains a drawing entity. Note that the value of the "source" member is not a drawing entity but a container that has a drawing entity:
http://widget.lai4d.org/lai4d_viewer.html?{{size}{{300}{200}}{source}{{{type}{drawing}{folder}{{{type}{sphere}{radius}{100}}{{type}{box}{diagonal}{{50}{100}{50}}{translate}{{100}{0}{0}}}}}}}

In this other URL sample the LAI4D widget is in design mode. The "size" member is not provided and it would have been ignored anyway because of the design mode. In this case the "source" member indicates a non-canonical drawing source since it contains two graphic entities instead of a drawing entity:
http://widget.lai4d.org/lai4d_designer.html?{{source}{{{type}{sphere}{radius}{100}}{{type}{box}{diagonal}{{50}{100}{50}}{translate}{{100}{0}{0}}}}}

Now this URL results in the same drawing as the previous one, but in this case the "sphere" entity is added to the drawing using the member "append" of the start-up instructions instead of through the "source" member. This is only an example, the combined usage of both "source" and "append" members in the start-up instructions has no sense:
http://widget.lai4d.org/lai4d_designer.html?{{source}{{{type}{box}{diagonal}{{50}{100}{50}}{translate}{{100}{0}{0}}}}{append}{{{type}{sphere}{radius}{100}}}}

This example uses the member "file" for indicating that the drawing source is stored in a file named "sample_a25" that must be retrieved from the LAI4D server. This could be the typical URL of a drawing intended to be displayed online assuming that the widget is loaded from the LAI4D official site:
http://widget.lai4d.org/lai4d_viewer.html?{{file}{{lai4d}{sample_a25}}}

In this case the member "file" indicates a remote URL for retrieving the source. This could be the typical URL of a drawing stored in the personal web space of the user intended to be displayed online assuming that the widget is loaded from the LAI4D official site:
http://widget.lai4d.org/lai4d_viewer.html?{{file}{http://www.mydomain.com/sample_drawing.l4d}}

Now the member "file" indicates a local text file from which to retrieve the drawing source (the real file extension is not relevant but must be indicated in order to find the file); the file is located in a directory named "sources" that is a child of the directory containing the LAI4D HTML file. It also indicates that the on screen controls must always be hidden. This could be the typical URL of a drawing intended to be displayed as an embedded IFRAME element in a HTML document prepared to be consumed not only online but also offline, in which case the LAI4D HTML page should be part of the document structure:
.../lai4d_viewer.html?{{file}{sources/sample.txt}{flags}{{controls hidden}}}

Suppose we have a file named "algorithm_a25" stored in the LAI4D server which defines a "program" entity intended to generate a especial geometry. In return suppose that "program" entity needs to be passed some arguments through its "variable" member, but it does not define such a member because it is expected that the user provides it through the start-up instructions. The "program" entity has a member "inherit" whose value points to an entity named "arguments" which is not defined in the original drawing. Then the user can provide the arguments to the "program" entity using the member "append" in the start-up instructions in order to append an entity named "arguments" defining the "variable" member to be inherited. Note that the value of the "append" member is not an entity but a container of entities. This could be the URL for that situation:
http://widget.lai4d.org/lai4d_viewer.html?{{file}{{lai4d}{algorithm_a25}}{append}{{{name}{arguments}{variable}{expected arguments}}}}

Some servers limit the maximum length of URLs in order to avoid abuses. Furthermore this limitation can also be imposed by the web browser. For example IE limits the URL length to 2048 bytes. This restriction is important when the drawing source is specified through the "source" member since large drawings can easily surpass the limit. The dynamic loading of files can be problematic for a number of reasons. The simplest cause could be an error in the file path. But it can also be a cross domain restriction or a limitation of the browser when working offline.

It is pretty obvious that what is going to be rendered in the viewport depends mainly on the drawing source. Therefore, the designer should keep attention not only to the start-up instructions but also to the "drawing" entity configuration, particularly to the members "view", "background color" and "flags", which directly affect to how the drawing is initially shown. See also the "Share" and "File" sections.

The Iquix framework provides additional functionality that can also be activated from the URL data. In LAI4D this possibility is used for manually configuring the UI language (the UI language is automatically set by default to that of the operating system). For example, putting the text "lang=es&" just after the "?" character and before the start-up instructions will set the UI language to Spanish. The text piece after the "=" character must be one of the supported two letter language codes. If not provided or not recognized, the default UI language is taken from the browser configuration which, in return, normally takes it from the operating system. When a suitable translated text cannot be found then the English version is used. This sample could be a complete URL specifying also the desired UI language:
http://widget.lai4d.org/lai4d_viewer.html?lang=es&{{file}{{lai4d}{sample_a25}}}
In case the UI language is going to be manually configured without start-up instructions then an empty start-up instructions ({}) should be provided. In other case the parser will consider that the start-up instructions are badly formed.

The official URLs for the LAI4D widget are: http://widget.lai4d.org/lai4d_viewer.html http://widget.lai4d.org/lai4d_designer.html Any other URL shall be considered provisional.

When a user intends to design and share a drawing online the most comfortable strategy consists of the following steps:

1. The user opens the official LAI4D designer web page.
2. Then creates the drawing. During the design process the user can use the "Browser's storage" function to quickly store and retrieve temporary drawings.
3. If the drawing uses "signal image" entities or integrates links which cannot be retrieved from the Internet then it is recommended to encapsulate those resources inside the drawing using the utility "Base64 file encoder".
4. When the drawing is finished, and if the user considers it convenient, the "Drawing metadata" function can be used in order to set in the drawing source the current view definition or the background color. In this way the drawing will be initially displayed as the designer expects.
   
5. Once the design is finished and ready to be published, the user saves the drawing using the function "Save server file" in order to store it in the LAI4D server making it available to the Internet. After the drawing is saved the server returns back the definitive name assigned to the drawing file which the user should keep. An URL for sharing the file is automatically shown too. If the user only needs that URL for sharing the drawing as a link then the next step is unnecessary.
   
6. Using the "Share" function the user can generate an URL for sharing the drawing as a link that can be directly sent to other users, or as an IFRAME element that can be embedded in HTML documents. By default the generated URL is exactly the same as that used for loading the widget, something useful in reader mode. The user must mark the check box "Use options" and then unmark the check box "Designer mode" if he wants to share the drawing in reader mode. The check box "Include file origin if available" should be already marked.
   

The URL generated in the last step should look something like:
http://widget.lai4d.org/lai4d_viewer.html?{{file}{{lai4d}{just_saved_file_name}}}

If the user has his own web space then to save the file to the LAI4D server is not necessary. The user can save the drawing source in a text file stored in his web space and then reference it using its absolute URL in the following way:
http://widget.lai4d.org/lai4d_viewer.html?{{file}{http://www.mydomain.com/sample_drawing.l4d}}

LAI4D can be used not only online but also offline. The LAI4D web page downloaded from the Internet can be saved to a local drive of the client machine using the standard "Save as" function of the web browser normally located in the "File" menu. This will allow the user to work offline regardless of whether the LAI4D page has been cached or not by the browser. This is particularly necessary if the user wants to create a distributable HTML document containing embedded LAI4D drawings as IFRAME elements that can be displayed both online from the Internet or offline from the local drive of a computer. The suggested steps for creating such a document are:

1. Create a main folder in the local drive intended to contain all the structure and resources of the document.
2. Inside the main folder create another folder for the LAI4D resources.
3. Use the web browser to connect to the latest version of the LAI4D viewer page at the LAI4D's official site. Then save it to the just created LAI4D folder using the "Save as" function of the web browser (use the 'complete HTML page' option to download all the resources). After this the LAI4D folder will usually contain the main LAI4D HTML page and a new folder with icons, CSS style sheets and JavaScript files. Check that the saved LAI4D HTML opens normally with the browser offline.
   
4. Inside the main folder create a new folder and place there all the source files of the LAI4D drawings that will be shown in the document.
   
5. Create the HTML document with the desired layout and the desired non-LAI4D content and place it inside the main folder.
6. Insert the necessary IFRAME elements (one for each drawing) in the HTML document. For each IFRAME:
1. Configure the desired size through the attributes "width" and "height".
2. Set the style properties "margin" to 0, "border" to 0, "overflow" to "hidden".
   
3. Configure the "src" attribute with a relative URL pointing to the saved LAI4D HTML file and with the start-up instructions indicating the corresponding drawing source file. It is not necessary to indicate the widget size in the start-up instructions since the widget will occupy the whole IFRAME area. See the "Widget initialization" section for more details. The "Share" function can also be useful.
   
4. The source code of the IFRAME element should look something like: <iframe src="lai4d/lai4d_viewer.html?{{file}{../drawing_sources/sample.l4d}}" style="margin: 0; border: 0; overflow: hidden;" height="200" width="300"></iframe>. Note that the path of the drawing source must be relative to the LAI4D HTML page.
   
7. The HTML document is ready. It can be distributed as normal computer files (a zip file with all the resources for instance) or it can be published (uploaded to a web server) in order to make it readable online. The users reading the document online will be able to save it to their computers using the standard "Save as" function of their browsers.
   

As previously mentioned, some browsers restrict certain functionalities (particularly local file access) while offline.

LAI4D can be essentially used in two ways or modes:

1. Reader mode: This mode is used to explore a 3D design changing the camera configuration and for querying information from the drawing like point coordinates, distances, user custom data, etc.
   
2. Design mode: This mode is an extended version of the reader mode and allows the user to create or modify a 3D drawing through the following main methods:
• Source edition: The drawing source is a set of entities described in the canonical language Lai4dCL that can be handled as plain text. This would be the preferred method for users not willing to invest time on learning how to work with the command and graphic interface because they only need to handle basic shapes and are going to make an occasional use of the tool.
• Command and graphic interface: In a similar way to that exposed by other conventional CAD tools, LAI4D also offers a set of functionalities which can be accessed by means of a command menu or selecting points and entities on the screen. Operations such as copy, move or rotate can be performed in a more comfortable manner using this kind of interface than using the source editor. The usage of the command and graphic interface, although clearly powerful, demands to the user an effort for learning several work-paths in order to achieve results in a comfortable and productive way. This is the reason because of the direct source edition can be better for inexperienced and occasional users.
  
• Design assistant: The simplest way to exploit a design tool is to find an expert that knows how to handle the tool and that simultaneously understands what the user wants to design. To develop a design assistant with such capabilities is the initial and main purpose of LAI4D. This technology is absolutely experimental and is at a very early stage of development. The first versions will be mostly focused on sketch conceptualization and computer vision techniques.

Both working modes can be used not only online but also offline. See the "Publishing LAI4D drawings" section for more details. The LAI4D widget in reader mode (LAI4D viewer) will be usually found embedded in other web pages as an IFRAME element whose URL indicates both the location of the LAI4D HTML file and the drawing source. Obviously the LAI4D widget can also be displayed in a dedicated web page, which is the normal situation for design mode (LAI4D designer). See the "Start-up process" section for more details.

In a desktop application the concepts of storage and retrieval are normally reduced to save or open a file in the machine's file system. However, in a web application the options related to storage and retrieval are wider. These options can be categorized according to the working scenario:

• Usage of the URL as container of the source: The string typed in the address bar of the web browser not only indicates the path of the navigated web page but also can include additional information such as the data source.
• Sources stored in the cloud: Remote servers hosting files or other web services can be requested to save or return a drawing source requiring some specific protocol.
• Local source files: In certain conditions a web application can also access files stored locally in the user's machine much the same as a desktop application does.
• Internal browser storage: Modern browsers are able to internally store in a persistent manner relatively large data packages that can be handled as files.
  

LAI4D exploits several strategies and web technologies for managing drawing sources because, depending on the user's intentions, some of them can be better than others. Since facilitating the sharing of designs is also an objective of the project, one of those options is the possibility of freely storing and retrieving drawing sources in the LAI4D server being this feature the easiest way for publishing LAI4D drawings on the Internet. But the user can also use another web space for this purpose.
In a similar way, those options can be classified according to where the data resides in the following groups:

• URL: The last part of the URL contains the start-up instructions which can indicate directly the drawing source or where to retrieve it from. See the "Widget initialization" and "Share" sections for more details.
  
• Server: The files are stored in a remote server and are publicly available on the Internet to any user having the file name in a read-only way. Particularly useful for sharing purposes. See the "Open server file" and "Save server file" sections for more details.
  
• Local: The files are stored in a local drive of the user's machine. See the "Open local file" and "Save local file" sections for more details.
• Browser: The files are stored internally in the own browser. Particularly useful for managing temporary drawings during the design work. See the "Browser's storage" section for more details.
  

Unfortunately some of the features intended to manage drawing sources in the own client machine may not work when the application runs offline and different browsers offer different capacities. Regarding the remote drawing sources, the user should be aware that, depending on the situation, difficulties may arise due to security restrictions. The good news for all users is that, regardless of the working scenario or any possible problem with the storage or retrieval functions, the LAI4D widget (reader or designer) always allows to inspect and copy the current drawing source as plain text; and in return the LAI4D designer widget always allows to set and edit the current drawing source as plain text.
The available LAI4D functions related to storage and retrieval can be analyzed in the sections "Share", "File" and "Publishing LAI4D drawings".

Regarding vector graphic capabilities, HTML5 offers two main approaches through the use of the canvas element, both covered by Iquix:

• The canvas 2D rendering context that allows to draw 2D geometries. 3D geometries can be painted only if they are previously projected using a convenient library like that found in the Iquix framework.
  
• The WebGL rendering context, which is also essentially a 2D drawing API but with the big difference that it exploits the graphics acceleration hardware present in the platform expressly designed to process at a high speed large amounts of 3D geometric data. This API again demands a special program for processing the 3D geometry in order to render it, a program that can also be provided by the Iquix framework.
  

Since both rendering contexts have different capabilities and the Iquix framework have different functions for handling them, the LAI4D interpreter acts as an abstraction layer trying to achieve a good degree of convergence in the drawing rendering process regardless of the rendering context used. In general the use of WebGL results in a better graphic quality and experience but unfortunately not all devices are WebGL enabled despite the web browsers do are compatible. LAI4D automatically detects the availability of WebGL and tries to use it if possible. If WebGL is not available then LAI4D will use the canvas 2D instead. This 2D rendering context, while offering a reasonably good experience, has some weaknesses:

• Complex drawings render slowly because the accelerated graphics hardware is not available. From a mathematical point of view, the necessary calculations for obtaining the projection of the 3D geometry are similar in both contexts, but in the canvas 2D context all those calculations must be performed by the main microprocessor which is not specialized in such calculations.
• The hiding of far objects by closer objects is imperfect. The perfect calculation of object hiding, while mathematically possible, is a process so heavy that it has to be replaced by a lighter algorithm based on calculating the painting order of the objects. To detect failures of object hiding is very easy even in not complex drawings. WebGL implements a more immediate and suitable strategy since hiding is computed pixel by pixel according to depth.
  
• Curved surfaces appear as polyhedrons because the calculation of curved surface brightness is too onerous, although not impossible. For the same reason polyhedrons are to be painted with a single color per face, while in WebGL they can define a color per vertex obtaining an interpolated face coloring.
  

Apart from the typical linear and surface geometries, LAI4D also handles signals. Signals are 2D graphic entities that are always painted parallel to the projection plane regardless of the camera orientation, although they have a 3D position and are scaled according to depth when rendered in perspective projections. They can be images, texts, circular dots and polygons. WebGL does not offer a means for generating texts so they are created in an auxiliary canvas 2D context and passed to the WebGL context as an image.
LAI4D supports RGBA colors, it is to say, colors with partial opacity or transparency. The projection engine of LAI4D does not perform photo-realistic rendering so the use of transparencies may lead to unrealistic results. Line widths are represented normally in canvas 2D contexts, but not all WebGL implementations consider line widths different from 1 pixel so graphic entities may be rendered ignoring line width specifications in WebGL rendering contexts.

To develop a standard CAD application with its conventional interface is not a priority of LAI4D. Indeed the implemented design tool has been developed with the idea of offering those functions that are less common in commercial CAD systems, but preserving a good degree of simplicity for inexperienced users. Therefore LAI4D does not try to imitate the structure or behavior of other professional design applications although more and more functionality can be added as the project progresses. The following is a non-exhaustive list of graphic functionalities that are not currently a priority for the project:

• Photo-realistic rendering.
• Usage of materials and textures.
• Advanced control of lighting.

The sketch interpreter implements Optical Character Recognition functionality intended to allow the assignment of measures to the generated hypothesis. It is specifically designed for recognizing numbers and completely runs on the client machine. This OCR is essentially based on a single layer convolutional neural network which allows a fast execution with a reasonable success rate.

The current version of LAI4D runs all the CAD and design assistant functionality on the client machine. This means that no information is sent to a remote server during the working process. This is also true for the "SEND" button of the design assistant. The "SEND" name is foreseen for the future when the heavy algorithms of the design assistant will need high performance computing. By now LAI4D is essentially an HTML5 application that can be executed offline.
Only the following functions depend on server side capabilities:

• Storage and retrieval of drawing files on the LAI4D server.
• Retrieval of drawing files from Internet locations using absolute URLs.
  

When the LAI4D HTML file is loaded in the web browser all the necessary resources like JavaScript files, CSS style sheets or image icons are also loaded. Although the LAI4D designer is an extension of the LAI4D viewer there are two different HTML files for them because the designer needs several resources unnecessary for the viewer. Once the resources are loaded the start-up process can be divided into the following steps:

1. If URL data has been provided then LAI4D reads it looking for start-up instructions. The URL data is the last part (query string) of the URL after the path of the HTML file. Some widget configurations and the drawing source can be specified in the URL data. Additionally the start-up instructions could indicate the non-standard functionality that should be loaded into the widget. In this step it is also possible to configure a custom UI language that is taken from the browser configuration by default.
   
2. The widget components are created and the layout is sized trying to fill the available window area. It is possible to indicate the widget size through the URL data. In reader mode the viewport occupies all the window area. In design mode a new component intended to show the design assistant is placed at the left or at the bottom of the viewport component depending on the window dimensions; additionally the page will have a header and a footer; the widget will have a minimum dimensions of 600×400 in landscape configuration or 400×600 in portrait configuration.
3. The LAI4D widget tries to retrieve the drawing source according to the start-up instructions indicated in the URL data if any. If no source is provided then an empty drawing is shown.
   
4. The drawing source is interpreted in order to translate the entities described into geometric information that can be rendered. Most of the possible LAI4D errors are reported in this step due to syntactic errors or fails in the structure of entities.
   
5. LAI4D selects one rendering context according to the browser capabilities (WebGL if possible) and then renders the geometric information resulting from the interpretation step displaying the drawing in the viewport.
   

Any error raised will be notified in a report of issues. See the "Issues" section for more details. The usage of the URL data for giving the initial configuration to the widget is explained in the section "Widget initialization".