It is possible to also associate an anchor to the destination node. A typical example would be to have links from the definition of a function in a C-program to the modules calling that function. In the destination nodes (these modules) the link would point to the actual call to the function. Another example is the use of links to the bibliography. Throughout this document you find references to related literature. Following these links not only takes you to the bibliography, but to a part containing the reference you want (i.e. the destination anchor). Here is an example: [DBHK92].
It is clear that the anchor is tied very closely to the designated part of the (source) node. In a number of hypertext systems however it is not possible to make the connection between the part of the node and the visual representation of the anchor. In HyperCard for instance, the anchors are just shapes (rectangles for instance) drawn on the background. It is the author's job to make sure the shape and the text of an anchor coincide on the screen. In a flexible system that lets you change the size of the windows, thus changing the linebreaks and the relative position of the words in the window, this approach would be unusable.
Although it is relatively easy to tie anchors to text, this is sometimes difficult or even impossible when the (source) node is not a text node. For instance, in a picture represented by a GIF of JPG image file it would be difficult to create an anchor that is connected to an object in the picture. The internal representation of the picture consists of raster graphics, not objects. This problem is usually circumvented by using (mostly rectangular) shapes as anchors, much like the kludgy way of placing anchors in HyperCard. Some graphical formats do offer the concept of objects, for instance VRML (Virtual Reality Markup Language), which is used to describe virtual worlds composed of 3D objects.