Could you please attach a screenshot with a marker of which character is wrongly possitioned? As a non chinese speaker it's not trivial for me to recognise what's wrong

Created attachment 58558 [details]
Please see the difference bwt the two readers.

Can you please use gimp, kolourpaint or any program to edit that screenshot and clearly mark where the problem is?

Created attachment 58559 [details]
Please see the circled regions.

Thanks :-)

Yet I've not checked the detail, but it seems that the vertical
centerlines of "蘿" and "蔔" are not completely synchronized
(the vertical lines of "艹" are slightly different) even in Adobe
Reader. In addition, I think all texts are rendered in vertical
writing mode (except of the page number, LithosPro?), but pdffonts
find a horizontal font; YenRoundZuinnEG-Md-ETen-B5-H-Identity-H.
I think it's related with this issue. I will check more in detail...

Created attachment 61086 [details]
sample PDF with guide rectangle

I attached a slightly modified sample. Please compare the results with
Adobe Reader (or Ghostscript) and poppler/xpdf. I added a rectangle to
show the expected positions. From the comparison, it is known that the
shifted character is NOT "蔔". Contrary, the correctly positioned glyph
is only "蔔", and other glyphs are shifted.

If you select each glyphs on Adobe Reader, you will find how "蔔" is
different from other glyphs. In most glyphs, the bopomofo annotation
is built-in. The fonts named "LinGothicZuinnEG-Bd-ETen-B5-V-Identity-V"
or like that are CID-keyed font, the glyph for one CID is a composite
glyph of Hanzi and annotation Bopomofo. Most texts are drawn by such
"pre-annotated" fonts. But "蔔" is exceptional. "蔔" is drawn by
the fonts like "LinGothic-Bold-ETen-B5-V-Identity-V". It is regular
Hanzi font, the glyph have no Bopomofo annotation.

I guess xpdf & poppler calculates the vertical centerline for the
annotated glyphs mistakenly, because the bounding box of the annotated
glyphs are not square.

Created attachment 61102 [details] [review]
experimental patch to fix this issue

Here is an experimental patch to fix this issue.
GfxFont::getNextChar() calculates the vector (vx,vy) to translate
the coordinate system from horizontal writing mode to vertical
writing mode, it uses the default glyph width & height of the font,
and external data to overwrite it. When GfxCIDFont object is created,
the width & height are set to 1.0 & -1.0 by default, and overwritten
if PDF has DW or DW2 values (out of font file stream). It seems that
what kind of FontBBox is written in the font file stream is not used
for the default width & height. I'm not sure if it is appropriate /or
not, but anyway, 1.0 & -1.0 are clearly incorrect if the bounding box
of the glyphs are not square. This patch calculates vx by the FontBBox
instead of default width. There would be 2 options;
vx = fontBBox[2] (right edge) - fontBBox[0] (left edge)
vx = fontBBox[2] (right edge) - 0 (origin)
From the experiment, it seems that former calculation is an
overcompensation.

I think this patch is half-baked. I should check if default width
should be calculated from fontBBox, and, the comment to fontBBox
member "for Type3" is correct (if so, I should not use fontBBox
for CID-keyed Type1!). Anyway, this patch shows a possible way to
fix this issue.

Created attachment 61104 [details]
result by experimental patch

The rasterization result with the patch

From the earlier PDF spec (1.3), the metrics defined by DW, W, DW2, W2
are requested to be consistent with those in the font file stream (see p.317)
Maybe FontBBox[] for all glyphs is not exact solution, per-glyph width
values should be retrieved via FoFi library, I think.

*** This bug has been marked as a duplicate of bug 89621 ***