Hi Troy, Lubos, Lubos Lunak píše v Pá 29. 07. 2011 v 19:52 +0200:
> > > > + sExpand.SearchAndReplaceAll( 0x0A, 0x0B ); > > > > > > This line looks strange. What is the reason for this? > > > > You'll find the same pattern in the binary .doc import/export. Newlines > > embedded in fields are 0x0B in .doc and 0x0A for us. Presumably the same > > is true in .docx > > I've noticed it in .doc as well, but .docx is XML, so this doesn't look > right > there. That's why I'm asking if there's any specific reason for this. Thank you very much for the patch! :-) I've pushed that: http://cgit.freedesktop.org/libreoffice/writer/commit/?id=607f7c2dd2549e979087f026da03a3310292f374 And added a comment: http://cgit.freedesktop.org/libreoffice/writer/commit/?id=17cfd534d10d7394679978e04a95543793f99e99 And then thought a bit more; and the 0xa -> 0xb is really necessary. The sExpand value goes to RunText, and only 0xb is handled as a newline there, see void DocxAttributeOutput::RunText(). So in the end, I had to push an amendment: http://cgit.freedesktop.org/libreoffice/writer/commit/?id=ba7c4b7bde85c5eb34ab64698dc9b7df88762319 Maybe instead of converting the 0xa to 0xb we could update DocxAttributeOutput::RunText(), but I think the conversion just in the field output is safer, who knows what other 0xa's we could have that should not be converted to newlines :-) Regards, Kendy _______________________________________________ LibreOffice mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice
