AU2016235011A1 - Curving text along a path - Google Patents

Abstract

-26 Abstract CURVING TEXT ALONG A PATH A method of warping a text glyph in a string of text. The string of text is positioned along a received curved path. A top path and bottom path along the string of text is generated 5 based on position of two equivalent points for each glyph in the string of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor. The weighting factor defines influence of a shape of the received curved path on a shape of the top path and bottom path. The glyph in the string of text is warped according to the curved path, the modified top path, and the modified bottom path. 11 Q222001 ID2AAAQ-7 C rifir-ti-n Ae EilArl -8/13 Fig. 8A 820 CDz Fig. 8B Fig. 8C 11823344 (11823344_1)

Description

CURVING TEXT ALONG A PATH TECHNICAL FIELD

The current invention relates generally to computer graphics and, in particular, to a system method and apparatus for warping glyphs. The current invention also relates to a computer program product including a computer readable medium having recorded thereon a computer program for warping glyphs.

BACKGROUND

The method of layout used for text varies depending on the presentation of the text. For documents and books, text is typically placed along a horizontal base path to provide maximum readability. For decorative text, it is common to distort, or warp, a string of text to provide a visually pleasing representation of the text. One method of controlling the warping of a text string is to place the text string along a curved base path. This method is commonly known as ‘text on a path’. The curved base path may match the curvature of another feature in the image (e.g., to place a text string along a curved road).

One method of implementing text on a path is to place the glyphs for a string of text along the curved path, oriented so that each glyph’s local y-axis is parallel to the normal vector for the path at the glyph’s position. No warping of the glyph geometry is performed. Placing the glyphs for a string of text along the curved path using such a method, improves rendering speed, but is not visually appealing.

More advanced methods of implementing ‘text on a path’, warp the geometry of each glyph, or the rendered string as a whole, so that the curvature of the base path is reflected in the glyph geometry.

In another ‘text on a path’ method, each glyph is skewed based on the tangent of the base path at the location where the glyph is placed, which can improve results for a limited set of path orientations. However, because the glyph is skewed and the vertical axis of the glyph is not re-oriented perpendicular to the base path, for path segments that rise or fall sharply (e.g., where the angle of inclination of the tangent is over 45 degrees) the skew transform renders the glyphs unreadable as shown for example at 810 in Fig. 8A.

In other methods, each glyph is transformed based on a mapping from the rectangular boundary that is usual for a glyph, to a warped polygon. The warped polygon is determined by projecting two points lying on the base path, where the base path intersects the glyph bounding box, outwards along the path normal at that point. The mapping of pixel co-ordinates in the glyph’s rectangular boundary to the calculated boundary is identical to UV texture mapping used in three dimensional (3D) rendering. However, distorting glyphs in such a manner results in distortion on the horizontal and vertical axis of the local co-ordinate space of the glyph.

Such distortion can result in comical looking text if the base path has a high curvature, especially at peaks and troughs. So while the text remains readable, the text may not be visually pleasing, as shown for example at 820 in Fig. 8B.

SUMMARY

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

According to one aspect of the present disclosure, there is provided a method of warping a text glyph in a string of text, the method comprising: positioning the string of text along a received curved path; generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the string of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and warping the glyph in the string of text according to the curved path, the modified top path, and the modified bottom path.

The method may further comprise, for each glyph in the string of text: generating a local top path for the glyph spanning a width of the bounding box of the glyph; and setting the generated local top path as the top path of the glyph.

In another implementation, the method may further comprise, for each glyph in the string of text: generating a local bottom path for the glyph spanning the width of the bounding box of the glyph; and setting the generated local bottom path as the bottom path of the glyph.

In an implementation, the method may further comprise: generating an initial top path and initial bottom path along the string of text based on the position of the equivalent point in each glyph in the line of text; and modifying the initial top path and initial bottom path according to the predetermined weighting factor to generate the top path and the bottom path.

Generally, the initial top path and initial bottom path both pass smoothly through a position of an equivalent point in each glyph in the string of text, the equivalent point being different for each of the initial top path and initial bottom path.

In an implementation, the top path and bottom path is generated based on a section of the path that falls within a rectangular region bounding the glyph.

In another implementation, the weighting factor is determined during rendering based on the geometry of the glyph base path.

Generally the glyph is located within a rectangular bounding box with parallel sides. A top and bottom of the rectangular bounding box may be modified according to the generated top path and generated bottom path.

According to another aspect of the present disclosure, there is provided an apparatus for warping a text glyph in a string of text, the apparatus comprising: means for placing the string of text along a received curved path; means for generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the line of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and means for warping the text character in the line of text according to the curved path, the modified top path, and the modified bottom path.

According to another aspect of the present disclosure, there is provided a non-transitory computer readable medium having a computer program stored thereon for warping a text glyph in a string of text, the program comprising: code for placing the string of text along a received curved path; code for generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the line of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and code for warping the text character in the line of text according to the curved path, the modified top path, and the modified bottom path.

Other aspects are also disclosed.

BRIEF DESCRIPTION OF THE DRAWINGS

One or more embodiments of the invention will now be described with reference to the following drawings, in which:

Fig. 1 is a schematic flow diagram showing a method of rendering text;

Fig. 2 is a schematic flow diagram showing a method of generating a ‘string top path’;

Fig. 3 is a schematic flow diagram showing a method of generating a local path;

Fig. 4 is a schematic flow diagram showing a method of warping a text glyph in a string of text;

Fig. 5 is a schematic flow diagram showing a method of warping a two dimensional (2D) bitmap according to a pre-generated ‘warp box’;

Figs. 6 and 7 collectively form a schematic block diagram of a general purpose computer system upon which arrangements described can be practiced;

Fig. 8 A shows glyphs rendered on a path in accordance with a text on a path method;

Fig. 8B shows glyphs rendered on a path in accordance with another text on a path method;

Fig. 8C shows glyphs rendered on a path in accordance with the method of Fig. 1;

Fig. 9 is a diagram, showing an invalid local top path that is manipulated to produce a valid local top path;

Fig. 10 shows an example of a Scalable Vector Graphics (SVG) file showing a format for describing ‘text on a path’;

Fig. 11 shows geometric elements used by a ‘local path generator’;

Fig. 12 is a schematic flow diagram showing a method of generating a path as executed in the method of Fig. 3;

Fig. 13 A shows glyphs positioned along a base path; and

Fig. 13B shows the glyph Έ’ from Fig. 13A including a glyph top path and a glyph base path.

DETAILED DESCRIPTION INCLUDING BEST MODE

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. ‘Text on a path’ is a feature of many graphical languages and graphics tools (e.g., the textPath element of scalable vector graphics (SVG)). The textPath element allows an author to define a path comprising curved and straight line segments. The path defined by the author is described below as the ‘base path’. The author also specifies a string of text and a font. The string of text resolves to one or more glyphs from the selected font. The glyphs may be represented in the font as a bitmap or as curved and straight line path segments. The string of text is positioned along the base path such that the baseline for each glyph lies on the base path and the glyph is oriented so that a local y-axis of the glyph is parallel to the normal vector for the base path at the position where the glyph is placed. A method 100 of rendering text is described below with reference to Fig. 1. The method 100 improves the visual quality of ‘text on a path’ so as to improve readability of the text. For example, Fig. 8C shows the glyphs 820 of Fig. 8A rendered 830 in accordance with the method 100.

In the method 100, glyphs may be warped in a single dimension so that the glyph flows along the base path, while retaining the visual characteristics of the font selected for the glyph. A weighting factor may be used to allow an author to control the influence that the curvature of the base path has over warping of glyphs. The weighting factor is configured for defining influence of a shape of the curvature of the base path on a shape of a top path and a bottom path as described below. The weighting factor enables the author to smooth out rapid changes of curvature in the base path that would result in a lot of distortion in the glyphs. As described in detail below, in one arrangement, the weighting factor may be predetermined. In another arrangement, the weighting factor may be determined during rendering of the glyphs based on the geometry of the glyph base path.

The described method 100 represents an extension to the SVG graphics language. However, the method 100 is equally applicable to other graphics languages (e.g., portable document format (PDF)) and graphics formats such as those used by Adobe Illustrator.

The SVG graphics language is an XML based representation for vector graphics. SVG includes a textPath element that allows a string of text to be positioned (or laid out) along a path. The path in SVG is defined with some combination of straight line segments and Bezier curves. The textPath element allows a number of attributes affecting the rendering of the string to be specified. Examples of such attributes are ‘fill’ and ‘stroke’ attributes that define paint (e.g., a solid colour, pattern, or gradient) rendered onto a display medium for the fill (i.e., the area within the glyph shape) Another example of an attribute that may affect the rendering of the string of text is stroke (i.e., the area around the boundary of the glyph shape).

Further attributes such as ‘startOffset’ and ‘spacing’, control the positioning of individual glyphs along the base path. The startOffset attribute defines the position along the length of the path that the rendering of the string begins, while spacing controls the distance between individual glyphs. The SVGtextPath element also supports a ‘method’ attribute that defines a rendering method used for the string of text.

The SVG graphics language ‘method’ attribute may be extended with an additional option to enable selection of the method 100 for rendering ‘text on a path’. The described method 100 thus becomes one of one or more selection options available to a user.

Alternatively, the PDF language, which provides a different format for defining graphics, but follows similar principals to SVG, also allows selection of the method 100 for rendering text on a path. In the PDF format, commands are added to the PDF language to set the graphics state such that text positioning and warping occurs while showing a string.

Figs. 6 and 7 depict a general-purpose computer system 600, upon which the various arrangements described can be practiced.

As seen in Fig. 6, the computer system 600 includes: a computer module 601; input devices such as a keyboard 602, a mouse pointer device 603, a scanner 626, a camera 627, and a microphone 680; and output devices including a printer 615, a display device 614 and loudspeakers 617. An external Modulator-Demodulator (Modem) transceiver device 616 may be used by the computer module 601 for communicating to and from a communications network 620 via a connection 621. The communications network 620 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 621 is a telephone line, the modem 616 may be a traditional “dial-up” modem. Alternatively, where the connection 621 is a high capacity (e.g., cable) connection, the modem 616 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 620.

The computer module 601 typically includes at least one processor unit 605, and a memory unit 606. For example, the memory unit 606 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 601 also includes an number of input/output (I/O) interfaces including: an audio-video interface 607 that couples to the video display 614, loudspeakers 617 and microphone 680; an I/O interface 613 that couples to the keyboard 602, mouse 603, scanner 626, camera 627 and optionally a joystick or other human interface device (not illustrated); and an interface 608 for the external modem 616 and printer 615. In some implementations, the modem 616 may be incorporated within the computer module 601, for example within the interface 608. The computer module 601 also has a local network interface 611, which permits coupling of the computer system 600 via a connection 623 to a local-area communications network 622, known as a Local Area Network (LAN). As illustrated in Fig. 6, the local communications network 622 may also couple to the wide network 620 via a connection 624, which would typically include a so-called “firewall” device or device of similar functionality. The local network interface 611 may comprise an Ethernet circuit card, a Bluetooth® wireless arrangement or an IEEE 802.11 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 611.

The I/O interfaces 608 and 613 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 609 are provided and typically include a hard disk drive (HDD) 610. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 612 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 600.

The components 605 to 613 of the computer module 601 typically communicate via an interconnected bus 604 and in a manner that results in a conventional mode of operation of the computer system 600 known to those in the relevant art. For example, the processor 605 is coupled to the system bus 604 using a connection 618. Likewise, the memory 606 and optical disk drive 612 are coupled to the system bus 604 by connections 619. Examples of computers on which the described arrangements can be practised include IBM-PC’s and compatibles, Sun Sparcstations, Apple Mac™ or like computer systems.

The method 100 and other methods described below may be implemented using the computer system 600 wherein the processes of Figs. 6 and 7 to be described, may be implemented as one or more software application programs 633 executable within the computer system 600. In particular, the steps of the method 100 are effected by instructions 631 (see Fig. 7) in the software 633 that are carried out within the computer system 600. The software instructions 631 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software may be stored in a computer readable medium, including the storage devices described below, for example. The software 633 is typically stored in the HDD 610 or the memory 606. The software is loaded into the computer system 600 from the computer readable medium, and then executed by the computer system 600. Thus, for example, the software 633 may be stored on an optically readable disk storage medium (e g., CD-ROM) 625 that is read by the optical disk drive 612. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 600 preferably effects an advantageous apparatus for the described methods.

In some instances, the application programs 633 may be supplied to the user encoded on one or more CD-ROMs 625 and read via the corresponding drive 612, or alternatively may be read by the user from the networks 620 or 622. Still further, the software can also be loaded into the computer system 600 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 600 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray™ Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 601. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 601 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs 633 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 614. Through manipulation of typically the keyboard 602 and the mouse 603, a user of the computer system 600 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 617 and user voice commands input via the microphone 680.

Fig. 7 is a detailed schematic block diagram of the processor 605 and a “memory” 634. The memory 634 represents a logical aggregation of all the memory modules (including the HDD 609 and semiconductor memory 606) that can be accessed by the computer module 601 in Fig. 6.

When the computer module 601 is initially powered up, a power-on self-test (POST) program 650 executes. The POST program 650 is typically stored in a ROM 649 of the semiconductor memory 606 of Fig. 6. A hardware device such as the ROM 649 storing software is sometimes referred to as firmware. The POST program 650 examines hardware within the computer module 601 to ensure proper functioning and typically checks the processor 605, the memory 634 (609, 606), and a basic input-output systems software (BIOS) module 651, also typically stored in the ROM 649, for correct operation. Once the POST program 650 has run successfully, the BIOS 651 activates the hard disk drive 610 of Fig. 6. Activation of the hard disk drive 610 causes a bootstrap loader program 652 that is resident on the hard disk drive 610 to execute via the processor 605. This loads an operating system 653 into the RAM memory 606, upon which the operating system 653 commences operation. The operating system 653 is a system level application, executable by the processor 605, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system 653 manages the memory 634 (609, 606) to ensure that each process or application running on the computer module 601 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 600 of Fig. 6 must be used properly so that each process can run effectively. Accordingly, the aggregated memory 634 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 600 and how such is used.

As shown in Fig. 7, the processor 605 includes a number of functional modules including a control unit 639, an arithmetic logic unit (ALU) 640, and a local or internal memory 648, sometimes called a cache memory. The cache memory 648 typically includes a number of storage registers 644 - 646 in a register section. One or more internal busses 641 functionally interconnect these functional modules. The processor 605 typically also has one or more interfaces 642 for communicating with external devices via the system bus 604, using a connection 618. The memory 634 is coupled to the bus 604 using a connection 619.

The application program 633 includes a sequence of instructions 631 that may include conditional branch and loop instructions. The program 633 may also include data 632 which is used in execution of the program 633. The instructions 631 and the data 632 are stored in memory locations 628, 629, 630 and 635, 636, 637, respectively. Depending upon the relative size of the instructions 631 and the memory locations 628-630, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 630. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 628 and 629.

In general, the processor 605 is given a set of instructions which are executed therein. The processor 605 waits for a subsequent input, to which the processor 605 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 602, 603, data received from an external source across one of the networks 620, 602, data retrieved from one of the storage devices 606, 609 or data retrieved from a storage medium 625 inserted into the corresponding reader 612, all depicted in Fig. 6. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 634.

The disclosed arrangements use input variables 654, which are stored in the memory 634 in corresponding memory locations 655, 656, 657. The arrangements produce output variables 661, which are stored in the memory 634 in corresponding memory locations 662, 663, 664. Intermediate variables 658 may be stored in memory locations 659, 660, 666 and 667.

Referring to the processor 605 of Fig. 7, the registers 644, 645, 646, the arithmetic logic unit (ALU) 640, and the control unit 639 work together to perform sequences of microoperations needed to perform “fetch, decode, and execute” cycles for every instruction in the instruction set making up the program 633. Each fetch, decode, and execute cycle comprises: a fetch operation, which fetches or reads an instruction 631 from a memory location 628, 629, 630; a decode operation in which the control unit 639 determines which instruction has been fetched; and an execute operation in which the control unit 639 and/or the ALU 640 execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 639 stores or writes a value to a memory location 632.

Each step or sub-process in the processes of Figs. 1 to 5 and 8A to 13 is associated with one or more segments of the program 633 and is performed by the register section 644, 645, 647, the ALU 640, and the control unit 639 in the processor 605 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 633.

The described methods may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the functions or sub functions of the described methods. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

The method 100 will be described by way of example with reference to Figs. 10, 13 A and 13B. As seen in Fig. 13A, two or more glyphs, such as glyph 1305 for text character Έ’ make up a string of text and are positioned along a base path 1310. A ‘string top path’ 1320 is generated by determining a path that passes through an equivalent point (e.g., point 1330) that lies at the same relative position within a ‘layout bounding box’ ( e.g., 1340) defining a rectangular region with parallel sides bounding the glyph 1305. The string top path 1320 passes through an equivalent point at the top of each glyph for the string of text. The layout bounding box for the glyph is a bounding box for the glyph that is the width of a ‘tight bounding box’ for the glyph and that is twice the height of an EM box of the font associated with the glyph. The layout bounding box is aligned with the glyph such that a baseline of the glyph runs horizontally through the layout bounding box at a halfway point.

As seen for example in Fig. 13B, for each glyph, such as the Έ’ 1305, a ‘glyph top path’ 1350 and a ‘glyph base path’ 1360 adjacent to the glyph 1305 are determined based on the intersection of ‘extended bounding box’ 1340, the string top path 1320 and the ‘string base path’ 1310 of the glyph 1305. As described in more detail below, the extended bounding box 1340 for the glyph 1305 is the bounding box which is the tight bounding box of the glyph 1305, extended vertically upwards and downwards by an amount so as to be a particular vertical size.

The glyph base path 1360 is the section of the base path 1310 that intersects the extended bounding box 1340. The glyph top path 1350 is the section of the string top path 1320 that intersects the extended glyph bounding box 1340.

The determined glyph top path 1350 is then modified so that the path 1350 is a weighted average of the glyph top path 1350 and the glyph base path 1360, with the glyph top path 1350 varying from base path 1310 according to a weighting factor. The weighting factor defines the weighting which is applied to the path 1350. As described above, the weighting factor may be predetermined. The weighting factor may be author controlled using an attribute on the SVG textPath element, or the weighting factor may be automatically generated based on the geometry of the glyph base path 1360.

Each glyph (e g., 1305) is warped vertically in a local co-ordinate space of the glyph 1305 such that the glyph 1305 fills a rectangular region 1345 defined by a tight bounding box of the glyph 1305. The tight bounding box 1370 is modified so that the top line segment of the tight bounding box 1370 is replaced by the modified glyph top path 1350 and the bottom line segment is replaced by the glyph base path 1360. The tight bounding box 1370 comprises the smallest possible box that includes all pixels painted for the glyph.

As an example, an author may produce an SVG file 1050, as seen in Fig. 10, containing text on a path in the form of a text string 1060 that is to positioned along a curved base path description 1055 defined via a textPath element 1051. The author may select the layout method for the textPath element using ‘mode’ attribute 1052. In the example of Fig. 10, when the value of ‘awesome’ 1053 is given for the ‘mode’ attribute 1052, the author opts in to the weighting based rendering method 100.

The method 100 begins at positioning step 110, where each glyph for the text string is positioned along a received base path, under execution of the processor 605. Any suitable method for positioning the string of text on a curved path, without overlapping the glyphs, may be used at step 110 to position the text on the received base path.

As one example of a suitable method for positioning text on a curved path, a second glyph may be positioned on the base path after a first glyph, using the advance width as per normal text layout conventions. Then, the curvature of the base path may be adjusted causing some parts of the glyph to be close together and hence overlap. Collision detection may then be performed on the first and second glyph and the second glyph may be advanced further along the base path until no overlap is detected.

In one arrangement of the method 100, a point, known as the ‘glyph path placement point’, lies on the y-coordinate of the baseline of the glyph, and at the x-coordinate at the centre of the glyph bounding box. The glyph is placed on the base path at step 110 such that the glyph path placement point lies on the base path. Each glyph is oriented relative to the path such that the local y-axis of each glyph is parallel to the vector normal for the base path at the point on the base path where the glyph path placement point lies.

As seen for example in Fig. 11, a vector normal 1130 for the base path is determined by determining a vector that lies 90 degrees anti clockwise from the slope of the base path at that point.

At generating step 120, an initial string top path and string bottom path are generated along the string of text. The initial string top path and bottom path are generated based on position of equivalent points for each glyph in the string of text by determining two curves that each pass through an equivalent point for each glyph. The initial string top path and string bottom path each pass through equivalent points of each glyph. The equivalent points for each glyph are adjacent the corresponding glyph. As described in detail below, the initial string top path and initial sting bottom path may be modified according to the weighting factor.

The string top path and string bottom path generated at step 120 may be stored in the memory 606, under execution of the processor 205. For the string top path, the equivalent point is the point at the top centre of the layout bounding box of the glyph. Similarly, for the string bottom path the equivalent point is at the bottom centre of the layout bounding box of the glyph. A method 200 of generating a string top path, as executed at step 120, will be described in more detail below with reference to Fig. 2. Once the string top path and string bottom path are determined at step 120, the method 100 proceeds to creating step 130, where the first glyph is selected, under execution of the processor 605.

Following step 120, the method 100 enters a loop, where the warp for each glyph is determined and applied.

For each glyph, a glyph top path is generated at generating step 135, a glyph base path is generated at generating step 140, and a glyph bottom path is generated at generating step 142. The glyph top path, glyph base path and glyph bottom path are per glyph versions of the string top path, string base path, and string bottom path, respectively, and are provided as input to step 150. The glyph top path, glyph base path and glyph bottom path are generated, in accordance with a method 300 which will be described in detail below with reference to Fig. 3. The method 300 may be referred to as a local path generator. The glyph top paths, glyph base paths and glyph bottom paths generated step 135 may be stored in the memory 606, under execution of the processor 605. As described in detail below, the glyph bottom path is a section of the string bottom path that intersects the extended glyph bounding box.

As seen in Fig. 10, the textPath element 1051 is extended with a ‘weight’ attribute that controls modification of the glyph top path and glyph bottom path, with the glyph top path and glyph bottom path varying according to the value of the weight attribute as described below.

The weight attribute is the weighting factor described above and allows an author to specify that the glyph warping should more closely follow the local bumpiness of the string base path, with the weight attribute defining influence of a shape of the curved string base path on a shape of the glyph top path and glyph bottom path. Similarly, the author may specify that the glyph warping should more closely follow the smoother string top path or string bottom path.

The smoothness of the string top path and string bottom path is a characteristic of the curve and is a result of the fact that those curves are generated based on relatively fewer data points (one per glyph), while the glyph base path may have many more controlling points. The weight attribute accepts values from zero to one inclusive. A value of zero for the weight attribute indicates the glyph top path and glyph bottom path should not be modified, while a value of one indicates the glyph top path and glyph bottom path should be equivalent to the glyph base path in curvature. A value between zero and one for the weight attribute indicates that the curvature of the glyph top path and glyph bottom path should be modified to be a weighted average of the curvature of that path, and of the glyph base.

At adjusting step 145, the glyph top path and glyph bottom path stored in the memory 606 are both modified, under execution of the processor 605, to be a weighted average of the glyph top path and the glyph bottom path. The ‘weight’ attribute controls the influence of the glyph base path, so, for any x-coordinate along the path, the adjusted paths y co-ordinate is determined in accordance with Equation (1):

(1) where y is the y co-ordinate of the glyph top path or glyph bottom path that is being adjusted, weight is the weighting factor, base-y is the y co-ordinate of the glyph base path, and base-yO is the first y-coordinate of the ‘glyph g’.

Alternatively, the weighting factor defining the weight may be determined based on the geometry of the glyph base path, rather than specified by the author. In the case that the weighting factor is determined, per glyph weighting may be used, and a separate weighting factor defining a different weight may be used for the glyph top path and glyph bottom path. Specifying so many weights is impractical for author specified weights. The weight, per glyph, that is used when modifying the glyph top path is determined based on the distance of the glyph top path to the glyph top path of other glyphs, and the weight that is used to modify the glyph bottom path is based on the distance of the glyph bottom path to the glyph bottom path of other glyphs.

The automatic weighting may be determined in accordance with Equation (2), below.

Equation (2) generally provides a weighting value of one. However, the weight moves towards zero if pi is within a short distance of p, where a short distance is defined as smaller than an EM box width: weight = min(distance(p, pi) / EM box width, 1) (2) where p is the ‘equivalent point’ on either the ‘glyph top path’ or ‘glyph bottom path’, depending on which weight is being determined, pi is the closest other equivalent point on another glyph’s ‘glyph top path’ or ‘glyph bottom path’. The geometry of the ‘glyph top path’ and ‘glyph bottom path’ is affected by the geometry of the ‘glyph base path’, as the ‘glyph base path’ specifies the position of the glyphs from which the points ‘p’ and ‘pi’ are determined.

The EM box is a glyph size metric stored within a font corresponding to the glyph. The dimensions of the EM box typically are those of the full body height of a font plus some extra spacing to prevent lines of text from colliding when typeset without extra leading.

At warping step 150, the glyph is warped, under execution of the processor 605, using the ‘glyph top path’, ‘glyph bottom path’, and the ‘glyph base path’, as a control. As described above, the glyph top path and glyph bottom path may be modified at step 145 based on the weight attribute. A method 400 of warping a text glyph in a string of text, as executed at step 150, will be described in detail below with reference to Fig. 4.

The method 100 continues to decision step 160, where if the last glyph in the text string has been selected at step 160, then the method 100 concludes. Otherwise, the method 100 proceeds to selecting step 110 where a next glyph in the text string is selected under execution of the processor 605.

The method 400 may be executed as one or more software modules of the software application program 633 resident in the hard disk drive 610 and being controlled in its execution by the processor 605.

The glyph is rendered within the font engine at step 410, to produce a two dimensional (2D) bitmap representation stored within a pixel array configured, for example, within the memory 606. The area of the pixel array is normalised so that the pixel array for each glyph has the same height. Therefore, at normalising step 420, if the pixel array is less than the height of the layout bounding box, then the pixel array is extended vertically up and down so that the pixel array is the height of the layout bounding box, with the baseline of the glyph running through the centre of the pixel array.

Then at dividing step 430, the pixel array is divided into two pixel arrays, under execution of the processor 605. The resulting pixel arrays contain the area of the glyph adjacently above the glyph base path and the area of the glyph adjacently below the glyph base path. The resulting pixel arrays may be stored in the memory 606. Each resulting pixel array is warped independently, but will align at the glyph base path.

At generating step 440, a warp box is generated within the memory 606, for warping the top pixel array. The warp box is generated by creating a rectangle equal to the dimensions of the pixel array, then substituting the path segment that runs across the top of the rectangle with the glyph top path, scaling the glyph top path as necessary so that the first and last vertices of the glyph top path lie at the same locations as the first and last vertices of the replaced line segment. The path segment that runs across the bottom of the rectangle is substituted with the glyph base path in a similar manner. The warp box generated at step 440 and the pixel array are passed as input to array warping step 450. A method 500 of warping a two dimensional (2D) bitmap according to a pre-generated warp box, as executed at step 450, will be described in detail below with reference to Fig. 5.

The warping method 500 iterates over each vertical line of pixels in the pixel array. The method 500 may be executed as one or more software modules of the software application program 633 resident in the hard disk drive 610 and being controlled in its execution by the processor 605.

The method 500 begins at selecting step 510, where a loop is entered and a first column of pixels of the pixel array is selected under execution of the processor 605. For each single pixel wide vertical slice of the glyph, the vertical slice is scaled linearly at scaling step 520, such that the top pixel of the vertical slice lies on the glyph top path and the bottom pixel of the vertical slice lies on the glyph bottom path.

At decision step 540, if the last column in the pixel array has been processed, then the method 500 concludes and the resulting pixel array is stored within the memory 606.

Otherwise, the method 500 returns to selecting step 510, where the next column of pixels of the pixel array is selected.

Referring back to the method 400 of Fig. 4, the warping process is repeated for the bottom pixel array, with a second warp box being generated at generating step 460. The second warp box has the top and bottom path segments substituted for the ‘glyph base path’ and ‘glyph bottom path’ respectively. The method 400 concludes at warping step 470, where the second warp box and bottom pixel array are warped in accordance with the method 500. The resulting top and bottom pixel arrays are now ready to be rendered to a display device, such as the display device 614, at the appropriate location and with the appropriate transformation.

The method 200 of generating a string top path and string bottom path, as executed at step 120, now be described with reference to Fig. 2. The method 200 may be executed as one or more software modules of the software application program 633 resident in the hard disk drive 610 and being controlled in its execution by the processor 605. As described below, the generated sting top path and string bottom path both pass smoothly through a position of an equivalent point in each glyph in the string of text, the equivalent point being different for each of the string top path and string bottom path.

The method 200 begins at initialising step 210, where a list configured within the memory 606 for holding the points through which the ‘string top path’ needs to pass through, is initialised to be empty.

Then at selecting step 230, the first glyph in the sequence of glyphs for the text string is selected under execution of the processor 205. Then, for the selected glyph, at determining step 240, a point relative to the glyph is identified, the point being an equivalent point for each glyph. For the ‘string top path’, the equivalent point is the point at the top centre of the layout bounding box for the glyph, and for the ‘string bottom path’ the equivalent point is at the bottom centre of the glyph’s ‘layout bounding box’.

At adding step 250, the point identified at step 240 is added to the list of points that the generated path needs to pass through. Than at decision step 260, if there are more glyphs in the text string, then the method 200 returns to step 270. The end result of steps 250 and 260 being, for each glyph, is a point is added to the list configured within the memory 606.

Once a point has been added to the list for each glyph, the method 200 proceeds to generating step 280, where the geometry of the generated string top path is determined under execution of the processor 605. The generated string top path begins at the point identified for the first glyph, ends at the point identified for the last glyph, and passes smoothly through the identified point for each glyph between the first and the last. In one arrangement, a Centripetal Catmull-Rom spline is determined using each identified point as a control point. Then at generating step 285, a string bottom path is generated under execution of the processor 605.

The method 300 of generating a local path is now described with references to Fig. 3.

The method 300, which may be referred to as a ‘local path generator’ function , takes a glyph and a ‘provided path’ as input. At step 135 described above, the ‘provided path’ is the string top path, at step 140 the ‘provided path’ is the base path, and at step 142 the ‘provided path’ is the string bottom path. The output of the method 300 is a path segment, which is used for the glyph top path at step 135, the glyph base path at step 140, and the glyph bottom path at step 142. The output path segment spans the entire width of the glyph adjacent the glyph.

As described below, for each glyph, the method 300 generates a local glyph top path and/or a local glyph bottom path for the glyph, the generated path spanning a width of the extended bounding box 1340 of the glyph. The generated local glyph top path and/or local glyph bottom path is set as the top path and/or bottom path of the glyph. The method 300 may be implemented as one or more software code modules of the software application program 633, resident in the hard disk drive 610 and being controlled in its execution by the processor 605.

The method 300 will be described by way of example with reference to the example glyph 1305 as shown in Fig. 11. The method 300 begins at the first step 310, where the extended bounding box 1340 for the glyph 1305 is generated under execution of the processor 605. The extended bounding box 1340 is generated by scaling the tight bounding box 1345 of the glyph 1305, in the local y-axis 1130 of the glyph 1305 by some factor. In the example of Fig. 11, the factor is three times, but alternative values may also be used.

Then at determining step 320, the intersection points of the provided path and the extended bounding box 1340 are determined in accordance with the processor 605. The intersection points are the first to enter the bounding box 1340, and the last to leave the bounding box 1340. Fig. 11 shows a successful determining step, where the intersection points of the provided path 1310 and the extended bounding box 1340 are points 1160 and 1165. It may also happen that there is only one, or no intersection points.

At decision step 330, if one or more intersection points were determined, then the method 300 proceeds to decision step 340. Otherwise, if there are zero intersection points, then the method 300 branches to setting step 360. Zero intersection points will be determined at step 330 if a length of the top path or bottom path adjacent the glyph is less than a width of the bounding box 1340.

At step 360, a horizontal line with width equal to the width of the extended bounding box 1340 is determined under execution of the processor 605.

If one or more intersection points are determined, at step 340, the method 300 further branches depending on whether one intersection point lies on each of the left and right boundaries of the extended bounding box 1340, with left and right being relative to the glyph upwards direction 1130. If one intersection point lies on each of the left and right boundaries of the extended bounding box 1340, then the method 300 proceeds to setting step 350. Otherwise, only one intersection point has been identified, or the identified intersection points do not lie on the left and right boundaries of the extended bounding box 1110, and the method 300 proceeds to generating step 370.

At step 350, if one intersection point lies on the left boundary of the extended bounding box 1340, and one intersection point lies on the right boundary of the extended bounding box 1340, then the output of the method 300 is the segment of the provided path 1310 that lies between the first intersection point 1160 and the second intersection point 1165.

At step 370, an output path is generated from intersection fragments, under execution of the processor 605. A method 1200 of generating a path, as executed at step 370, will now be described with reference to Fig. 12.

The method 1200 may be implemented as one or more software code modules of the software application program 633 resident in the hard disk drive 610 and being controlled in its execution by the processor 605.

The method 1200 will be described by way of example with reference to Figs. 9A and 9B, which show two intersection points 930 and 935, where the points 930 and 935 do not fall on the left or right boundaries of extended bounding box 905.

The method 1200 begins at decision step 1210, where if two intersection points have been identified, then the method 1200 proceeds to step 1250. If only one intersection point has been identified, then the method 1200 proceeds to decision step 1220.

At step 1220, the x and y co-ordinates of the first control point 930 for the provided path 910 are examined to determine if the x and y co-ordinates fall within the region of the extended bounding box 905. If it is determined that the x and y co-ordinates fall within the region of the extended bounding box 905, then the method 1200 proceeds to step 1230. Otherwise, the method 1200 proceeds to step 1240.

The first control point is used as the second intersection point at control point step 1230. Otherwise, the last control point for the provided path 910 is used as the second intersection point at control point step 1240.

Then, the method 1200 proceeds to step 1250, where one intersection point is designated as the left intersection point, and the other intersection point is designated as the right intersection point. In the example of Fig. 9A and 9B, the intersection point with the minimum x co-ordinate 930 is designated the left intersection point. The intersection point with the maximum x co-ordinate 935 is designated the right intersection point.

Then, at moving step 1260, the x co-ordinate of the left intersection point 930 is set equal to the x co-ordinate of the left side 940 of the extended bounding box 905. The x coordinate of the right intersection point 935 is set to x co-ordinate of the right side 945 of the extended bounding box 905 at moving step 1870. The position of the Bezier handles for each control point are not changed.

The result of the method 300, including the method 1200, is a path segment that spans the entire width of the extended bounding box 905 and is suitable as a control for warping a glyph.

Industrial Applicability

The arrangements described are applicable to the computer and data processing industries and particularly for image processing.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

In the context of this specification, the word “comprising” means “including principally but not necessarily solely” or “having” or “including”, and not “consisting only of’. Variations of the word "comprising", such as “comprise” and “comprises” have correspondingly varied meanings.

Claims (11)

1. A method of warping a text glyph in a string of text, the method comprising: positioning the string of text along a received curved path; generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the string of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and warping the glyph in the string of text according to the curved path, the modified top path, and the modified bottom path.

2. The method according to claim 1, further comprising the steps of, for each glyph in the string of text: generating a local top path for the glyph spanning a width of the bounding box of the glyph; and setting the generated local top path as the top path of the glyph.

3. The method according to claim 1, further comprising the steps of, for each glyph in the string of text: generating a local bottom path for the glyph spanning the width of the bounding box of the glyph; and setting the generated local bottom path as the bottom path of the glyph.

4. The method according to claim 1, further comprising the steps of: generating an initial top path and initial bottom path along the string of text based on the position of the equivalent point in each glyph in the line of text; modifying the initial top path and initial bottom path according to the predetermined weighting factor to generate the top path and the bottom path.

5. The method according to claim 3, wherein the initial top path and initial bottom path both pass smoothly through a position of an equivalent point in each glyph in the string of text, the equivalent point being different for each of the initial top path and initial bottom path.

6. The method according to claim 1, wherein the top path and bottom path is generated based on a section of the path that falls within a rectangular region bounding the glyph.

7. The method according to claim 1, wherein the weighting factor is determined during rendering based on the geometry of the glyph base path.

8. The method according to claim 1, wherein the glyph is located within a rectangular bounding box with parallel sides.

9. The method according to claim 8, wherein a top and bottom of the rectangular bounding box is modified according to the generated top path and generated bottom path.

10. An apparatus for warping a text glyph in a string of text, the apparatus comprising: means for placing the string of text along a received curved path; means for generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the line of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and means for warping the text character in the line of text according to the curved path, the modified top path, and the modified bottom path.

11. A non-transitory computer readable medium having a computer program stored thereon for warping a text glyph in a string of text, the program comprising: code for placing the string of text along a received curved path; code for generating a top path and bottom path along the string of text based on position of two equivalent points for each glyph in the line of text, the top path and bottom path varying from the received curved path according to a predetermined weighting factor, the weighting factor defining influence of a shape of the received curved path on a shape of the top path and bottom path; and code for warping the text character in the line of text according to the curved path, the modified top path, and the modified bottom path. CANON KABUSHIKI KAISHA Patent Attorneys for the Applicant/Nominated Person SPRUSON & FERGUSON