As an addendum to @Frank's answer:
Deviations
There are some deviations from the PDF specification in the PDF in the answer.
in the page content stream (object 5) the XObject A is drawn from within a text object:
BT
70 50 TD % this has no effect on `/A Do` - only on the "manual" `Tj`
/A Do % do the drawing of XObject A
This is not allowed, cf. section 8.2, especially figure 9 at its end: XObjects may only be inserted at the page description level of the content of a page or XObject.
in the XObject content stream (object 6) a font is referenced
/F1 12 Tf
but no font resources are defined:
/Resources << /ProcSet [ /PDF ] >>
This is not allowed, The Tf operator shall specify the name of a font resource—that is, an entry in the Font subdictionary of the current resource dictionary (section 9.2.2 of the specification) which here is the resource dictionary of the XObject, not the page.
In very early versions of the PDF format a XObject could inherit resources of the page if it omitted the Resources entry... This construct is obsolete and should not be used by conforming writers (section 7.8.3 of the PDF specification) and in the example at hand, the Resources entry is not even omitted after all.
in the XObject content stream (object 6) the text showing operator Tj is used outside a text object:
stream
%70 50 TD % without this `TD` setting, `/A Do` places this in 0,0 - bottom left corner
/F1 12 Tf
(Hello, world!) Tj
endstream
This is not allowed, cf. section 8.2, especially figure 9 at its end: Text showing operators are only allowed in text objects, and as XObject shall not be used inside text objects, this stream cannot be considered to reside in one.
As it displays the XObject nonetheless, evince seems to be quite forgiving concerning PDF validity issues, even more forgiving than the Adobe Reader which already is very forgiving but shows that PDF as:
i.e. it does not display the XObject at all.
Adapted sample
This section contains an adapted sample which is nearer to the specification.
Furthermore the wish of the OP to position the XObject more freely is taken into account:
%PDF-1.4
1 0 obj % entry point
<<
/Type /Catalog
/Pages 2 0 R
>>
endobj
2 0 obj
<<
/Type /Pages
/MediaBox [ 0 0 200 200 ]
/Count 1
/Kids [ 3 0 R ]
>>
endobj
3 0 obj
<<
/Type /Page
/Parent 2 0 R
/Resources <<
/XObject <<
/A 6 0 R
>>
>>
/Contents 5 0 R
>>
endobj
4 0 obj
<<
/Type /Font
/Subtype /Type1
/BaseFont /Times-Roman
>>
endobj
5 0 obj % page content
<<
/Length 588
>>
stream
% draw xobject at 0, 0
/A Do
% draw xobject at 20, 180
q
1 0 0 1 20 180 cm
/A Do
Q
% draw xobject at 100, 100, with different scales and rotations applied
q
1 0 0 1 100 100 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
0.7 0.5 -0.5 0.7 0 0 cm
/A Do
Q
% draw xobject at 120, 180, skewed somewhat
q
1 0 0.3 1 120 180 cm
/A Do
Q
endstream
endobj
6 0 obj
<< /Type /XObject
/Subtype /Form
/FormType 1
/BBox [ 0 0 1000 1000 ]
/Matrix [ 1 0 0 1 0 0 ]
/Resources <<
/ProcSet [ /PDF ]
/Font <<
/F1 4 0 R
>>
>>
/Length 130
>>
stream
BT
/F1 12 Tf
% To not cut off stuff below the base line, namely parts of the comma
1 0 0 1 0 3 Tm
(Hello, world!) Tj
ET
endstream
endobj
xref
0 7
0000000000 65535 f
0000000010 00000 n
0000000079 00000 n
0000000173 00000 n
0000000301 00000 n
0000000380 00000 n
0000000450 00000 n
trailer
<<
/Size 7
/Root 1 0 R
>>
startxref
600
%%EOF
(Cross reference entries and stream lengths surely are wrong.)
This results (as seen in Adobe Reader):
All the "Hello, world!" instances are generated using the single XObject of the PDF.
