> Lars wrote: >On Wed, 2007-01-31 at 11:19 +1030, Young, Robert wrote: >> >> Hmmm, my only testing has been with the test documents >> >attached to the >> >> bug 332544. Do you have a simple example you could send me or >> >> attach to the bug report and I'll get it to work too? >> >> >> > >> >It is hardly worth posting an example. Just create some text in >> >cmr10 and set the size to 0.35. If your change makes it output >> >'scaled 0.67' (approximately 2.05/3.0) then we have a problem. If >> >it still outputs 'scaled 1.05' then everything is normal. >> > >> >> OK, I've updated the test cases attached to the bug 332554 >> http://bugzilla.gnome.org/show_bug.cgi?id=332554 (sorry for getting >> the number wrong before) >> >> The new test case has cmr, serif, sans and monospace. As a >result I've >> updated the patch to try to fit those font sizes. >> >> Unfortuntely there seems to be such a difference in the fonts used >> that the scaling is quite different for them all. I like >Lars' idea of >> getting LaTex to fit the text to the given width using kerning, but >> it's just so way out at the moment that this will cause problems. >> Maybe the font name matching needs improving instead? > >Is it really so way out? I added a patch to the bug that uses >text_line to get the right width and do a \makebox for it. It >seems right to me, but mptopdf complains. Obviously, it needs >to not use the calculated scale factor, and there may be a >different scale factor involved instead >(0.7 seems to be common:), but I want to see if text_line can >be made to work. Test on the samples/render-test.dia file, it >has text that will be rendered with the text_line bit. > >> As an aside, I note that the error in the text scaling is >non linear - >> it changes depending on the font size. This seems to be a font >> dependant characteristic - it occurs in Dia and MetaPost. >The attached >> example has font size 2, 1, 0.5, 0.25 for three font styles. >The .png >> shows what it looks like in Dia, and .pdf via metapost export (with >> the latest patch to bug 332554). > >And that is *exactly* why we need text_line. Even in GTK >land, text scaling isn't linear, it's even worse in TeX land >because of the fine typesetting.
I completely agree that text_line is required for GTK and export to PS, PDF, bitmaps, etc. Users should be able to get reliable WYSYWIG export for these types of formats where fonts can be embedded or rendered directly. I'm of two minds on SVG... However, maybe I don't understand the complete picture here, but there are always going to be issues with fonts when exporting to some formats, like metapost. By forcing the exported output to be fitted to a box that is the wrong size for the resulting font/typesetting algorithm (because as you have said TeX has different typesetting to GTK), we are trying to force a square peg in a round hole. If we had a LaTex render, it would be a different story. No one has the time to do one before 0.96 comes out. So my patch was aiming for something that would work in most instances. Using text_line blows up on equations, where as my proposed patch at least leaves the right/centre/left alignment correct, and gets the odd text width wrong (but within a couple of percent for sans, serif and monospace). I am very keen to receive examples of where it doesn't work so that I can improve it. Regards, Rob. _______________________________________________ Dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://www.gnome.org/projects/dia/faq.html Main page at http://www.gnome.org/projects/dia
