Menu
▾
▴
xmlroff-list
|
From: Tony G. <Ton...@Su...> - 2003-03-19 17:13:13
|
Are people receiving spam from 'Ifujian' through their email address used by SourceForge and/or the address used by the xmlroff-list mailing list? This list is being (unsuccessfully) spammed by 'Ifujian', and so are both my work and private SourceForge personas. Since xmlroff is the only place where all three overlap, I'm wondering if anybody else is being similarly spammed. It is sufficient to reply to me privately. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-03-20 17:49:02
|
Tony Graham wrote at 19 Mar 2003 17:12:45 +0000: > This list is being (unsuccessfully) spammed by 'Ifujian', and so are > both my work and private SourceForge personas. Since xmlroff is the > only place where all three overlap, I'm wondering if anybody else is > being similarly spammed. Since no-one else has said they are being spammed, I guess I must be privileged. While I'm glad that no-one else is being spammed, that's one privilege I can do without. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-04-16 00:46:04
|
Jesper Stigberg and I started out by discussing his Windows port of
xmlroff, but the discussion is now more general, so we're moving it
here.
Jesper Stigberg wrote at 15 Apr 2003 22:41:01 +0200:
> Tony Graham wrote:
> > Jesper,
> >
> > Can we move this exchange to pangopdf-list or xmlroff-list?
>
> Yes, please forward this to one of the lists if you think there is enough
> context/background.
>
> >
> > Jesper Stigberg wrote at 14 Apr 2003 13:40:35 +0200:
> > > Tony Graham wrote:
> > > > I've added pango-xsl-attributes.[ch] to CVS so some includes of
> > > > pangopdflib.h have changed to including pango-xsl-attributes.h.
> > >
> > > Excelent news. One question: Do we really need separete
> > > pangopdflib-layout.[hc], pangogp-layout.[hc] etc? Couln't we manage
> > > with pango-xsl-layout.[hc]? I havn't looked at pangogp-layout.[hc]
> > > but I would belive that the algorithms for keeps/breaks etc are the
> > > same for the different implementations.
> >
> > I also wish that we didn't need separate
> > pango{pdflib,gp}-{layout,fontmap}.[ch], etc., but doing so seems the
> > current 'Pango Way'.
> >
> > pangopdflib*.[ch] borrowed heavily from pangoft2*.[ch], and
> > pangogp*.[ch] is little more than a search-and-replace on
> > pangopdflib*.[ch] with a bit of a rewrite of the pango_gp_render*()
> > functions.
> >
> > It would be simpler if there was a parent type of PangoGPLayout,
> > PangoPDFLIBLayout, and PangoFT2Layout that handled the common code.
> >
> > > What I'm trying to say is that instead of libpango.[so|dll] and
> > > libpangopdflib.[so|dll] or libpangogp.[so|dll] we could have
> > > libpango.[so|dll] ( with no xsl specific code) libpangoxsl[so.dll]
> > > (with the general/common xsl stuff ) and libpangogp.[so|dll] (
> > > which handles rendering, fonts etc )
> >
> > One thing that should be done in the base Pango code is to make all
> > the stuff in pangofc-fontmap.cI into a GObject class that is a child
> > type of PangoFontMap. PangoGPFontMap, PangoFT2FontMap, and
> > PangoPDFLIBFontMap could then be child types of that type and save a
> > lot of duplicate code. I haven't done it in PangoPDF because it would
> > complicate updating PangoPDF when the base Pango changes.
> >
> > There was something that I thought of doing when I added
> > fo-pango-context.[ch] to xmlroff that would greatly reduce the
> > dependence of xmlroff modules on Pango headers, but I didn't do it
> > then because it would be a lot of work, but now I've forgotten the
> > details of what I wanted to do. It should come back to me while I'm
> > tinkering with xmlroff to add pangogp support.
> >
> > I am hoping that FoPangoContext can separate xmlroff from most of the
> > details of Pango backends. That's also part of why the pangogp
> > render() functions take a PangoContext and not a GnomePrintContext,
> > but that really only works because the GNOME Print backend only works
> > on one GnomePrintContext at a time, whereas the FT2 or xft backend
> > could be expected to render to multiple bitmaps associated with one
> > PangoContext.
> >
> > As an aside, I'm pleased that pangogp can render Thai and Arabic,
> > which pangopdflib can't.
>
> Because of PDFLib?
>
> > On the downside, pangogp can't do CJK, which
> > pangopdflib can (if you only use the standard Adobe fonts). Can your
> > Win32 screen renderer handle non-Roman scripts?
>
> I haven't tried yet, but I don't think there should be any problems thats not
> solvable.
>
> >
> > > > Are you working from the CVS version of xmlroff or the released
> > > > version?
> > >
> > > For xmlroff I did the last cvs update about a week ago. For pango,
> > > I have used one of the first of your releases.
> >
> > I'm glad that you're using the CVS version.
> >
> > xmlroff changed today, for the first time in about two weeks, because
> > of pango-xsl-attributes.[ch].
> >
> > > FYI, I did some hacking on the win32 'screen-render' ( I really don't know what
> > > to call it ) during the weekend and can know render xmlroff.fo reasonably ok (
> > > there are some problems with line height/spacing and font sizes ).
> > >
> > > About FoDoc, in win32 you have to explicit begin/end a path before
> > > you strike/fill it but in PDFLib it seems that a path is implicit
> > > begun/ended, so maybe there could be a
> > > fo_doc_begin_path/fo_doc_end_path function in FoDoc, which is not
> > > implemented for FoDocPDFLIB. I don't know how GNOME print behaves
> > > in respect to this. I realise that win32 isn't a primary platform
> > > fo you so this is just a suggestion.
> >
> > Win32 is not a primary platform for me, but Win32 support would
> > greatly add to the appeal of xmlroff, so I do want to support it.
> >
> > Where do you also need to add fo_doc_begin_path/fo_doc_end_path in
> > area-to-pdf.c?
> >
>
> Surounding the 'function calls'/figures that should be part of the path
>
> fo_doc_begin_path(...);
> ....
> fo_doc_move_to(...);
> fo_doc_line_to(...);
> ....
> fo_doc_end_path(...);
>
> fo_doc_fill_stroke(...);
>
> or did I misunderstand you?
>
> To be frank, I have just implemented fo_doc_{begin,end}_page, fo_doc_translate,
> fo_doc_move_to etc and concentrated on pango to see if I can get the text layout
> correctly (well, I did fo_doc_line_to for debugging), so I haven't really given
> it enough thought (will post a suggestion/patch when I have).
>
> > I also need to see what GNOME Print requires for beginning and ending
> > paths, and it may well require explicit begin and end calls.
> >
> > > Is there a document somewere describing the units used, coordinat
> > > systems and other details of xmlroff?
> >
> > The XSL Recommendation?
> >
> > Ask your questions on the xmlroff-list or on the Wiki and I will do my
> > best to answer them.
>
> Will do.
>
> Regards,
> Jesper
>
>
|
|
From: Tony G. <Ton...@Su...> - 2003-04-16 01:00:49
|
Jesper Stigberg wrote at 15 Apr 2003 22:41:01 +0200:
> Tony Graham wrote:
...
> > As an aside, I'm pleased that pangogp can render Thai and Arabic,
> > which pangopdflib can't.
>
> Because of PDFLib?
Yes. Thai and Arabic have context-dependent glyphs. The GNOME Print
backend uses GNOME Print glyphlists, so there's no problem. The
PDFlib backend has to map glyphs back to glyph names in the Adobe
Glyph List (AGL) (and not the current AGL version, at that). When a
font doesn't use a glyph name from the supported AGL version, PDFlib
can't cope.
> > On the downside, pangogp can't do CJK, which
> > pangopdflib can (if you only use the standard Adobe fonts). Can your
> > Win32 screen renderer handle non-Roman scripts?
>
> I haven't tried yet, but I don't think there should be any problems thats not
> solvable.
That's good. I've since found problems with both my Arabic and Thai
implementations.
I'm using the pangoft2topgm program from the Pango examples directory
and lines from HELLO.utf8 as my benchmark for script support.
...
> > Where do you also need to add fo_doc_begin_path/fo_doc_end_path in
> > area-to-pdf.c?
> >
>
> Surounding the 'function calls'/figures that should be part of the path
>
> fo_doc_begin_path(...);
> ....
> fo_doc_move_to(...);
> fo_doc_line_to(...);
> ....
> fo_doc_end_path(...);
>
> fo_doc_fill_stroke(...);
>
> or did I misunderstand you?
That is what I asked, thank you.
> To be frank, I have just implemented fo_doc_{begin,end}_page,
> fo_doc_translate, fo_doc_move_to etc and concentrated on pango to
> see if I can get the text layout correctly (well, I did
> fo_doc_line_to for debugging), so I haven't really given it enough
> thought (will post a suggestion/patch when I have).
So you have both a new FoDoc variant and a new Pango backend variant?
Or just a FoDoc variant for the Win32 backend of Pango?
Regards,
Tony Graham
------------------------------------------------------------------------
XML Technology Center - Dublin
Sun Microsystems Ireland Ltd Phone: +353 1 8199708
Hamilton House, East Point Business Park, Dublin 3 x(70)19708
|
|
From: Jesper S. <je...@no...> - 2003-04-16 12:40:07
|
Tony Graham wrote: > > So you have both a new FoDoc variant and a new Pango backend variant? > Or just a FoDoc variant for the Win32 backend of Pango? > I have both a new implementation of FoDoc and a new pango backend. The reasons for the new pango version are: * had to incorporate your xsl-attributes and layout changes * pango-win32 assumed a coordinate system where (0,0) is in the upper left corner growing down for increasing Y, xmlroff/PDFLib uses the lower left corner for (0,0). I also had to change area-to-pdf, since it used PDFLib, but I don't think that it would be to hard to avoid that. If that happens perhaps area-to-pdf could be renamed to something like render-area.[hc]? Regards, Jesper |
|
From: Tony G. <Ton...@Su...> - 2003-04-21 12:30:57
|
Jesper Stigberg wrote at 16 Apr 2003 14:43:23 +0200: > I have both a new implementation of FoDoc and a new pango backend. > > The reasons for the new pango version are: > > * had to incorporate your xsl-attributes and layout changes > * pango-win32 assumed a coordinate system where (0,0) is in the upper left > corner growing down for increasing Y, xmlroff/PDFLib uses the lower left corner > for (0,0). I understand. Are you able to contribute your code to xmlroff or PangoPDF? > I also had to change area-to-pdf, since it used PDFLib, but I don't > think that it would be to hard to avoid that. If that happens > perhaps area-to-pdf could be renamed to something like > render-area.[hc]? The current CVS code has fo_doc_render_layout() and fo_doc_render_layout_lines() so area-to-pdf no longer has any dependency on PDFlib. area-to-pdf is called that because it described what was happening at the time. Now that none of area-to-pdf uses PDFlib, it is also possible to break up area-to-pdf and put each area type's code into the area type's implementation of the currently unused 'draw' function of FoArea. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Jesper S. <je...@no...> - 2003-04-25 14:46:17
|
Tony, All, Sorry for the late reply. Tony Graham wrote: > > Are you able to contribute your code to xmlroff or PangoPDF? > Yes, as soon as I have some more time and the code is in reasonable shape I will. Perhaps the best thing would be to write the 'screen renderer' in a cross platform tool kit (wxWindows,QT,GTK+) and use a pango backend based on FT2/fontconfig. > > I also had to change area-to-pdf, since it used PDFLib, but I don't > > think that it would be to hard to avoid that. If that happens > > perhaps area-to-pdf could be renamed to something like > > render-area.[hc]? > > The current CVS code has fo_doc_render_layout() and > fo_doc_render_layout_lines() so area-to-pdf no longer has any > dependency on PDFlib. Time to sync with cvs. Greate! > > area-to-pdf is called that because it described what was happening at > the time. > > Now that none of area-to-pdf uses PDFlib, it is also possible to break > up area-to-pdf and put each area type's code into the area type's > implementation of the currently unused 'draw' function of FoArea. > Is this something you are planning todo in the nearest future? And now ower to something completely different. *** If I understand xmlroff correctly you are using pt as 'device-unit'. This works ok when using pangopdflib since it too (I assume) use pt as unit, but my pango-win32 backend use pixel as unit. The result of this is that all lengths/widths/heights are sometimes measured in pixel (when they are 'received' from pango) and sometimes in pt. It's not possible to know when to convert from pt to px and when not to do it. I can see two solutions to this: 1. All pango-backends compatible with xmlroff must use pt as a unit. 2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from pango-device-units to xmlroff-device-units. 1. will loose precision and will not be compatible with: http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit 2. seems the way to do it. I don't know if there is an API in pango that lets you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo. Thoughts? Have a nice weekend, Jesper. *** May contain traces of nuts. |
|
From: Tony G. <Ton...@Su...> - 2003-04-29 16:46:19
|
Jesper Stigberg wrote at 25 Apr 2003 16:50:25 +0200: > Sorry for the late reply. That's okay. I've only just got back from the second half of my vacation. > Tony Graham wrote: > > Are you able to contribute your code to xmlroff or PangoPDF? > > > > Yes, as soon as I have some more time and the code is in reasonable shape I will. Great. > Perhaps the best thing would be to write the 'screen renderer' in a cross > platform tool kit (wxWindows,QT,GTK+) and use a pango backend based on > FT2/fontconfig. There is a QT example in the core Pango examples that may be useful to you. ... > > Now that none of area-to-pdf uses PDFlib, it is also possible to break > > up area-to-pdf and put each area type's code into the area type's > > implementation of the currently unused 'draw' function of FoArea. > > Is this something you are planning todo in the nearest future? It's actually something that I've wanted to do for a long time but haven't > And now ower to something completely different. > > *** If I understand xmlroff correctly you are using pt as 'device-unit'. This > works ok when using pangopdflib since it too (I assume) use pt as > unit, but my pango-win32 backend use pixel as unit. The result of > this is that all lengths/widths/heights are sometimes measured in > pixel (when they are 'received' from pango) and sometimes in > pt. It's not possible to know when to convert from pt to px and > when not to do it. Yes, xmlroff uses pt as the 'device-unit'; i.e., it converts all dimensions in the FO expressions into points. I haven't looked at the Pango Win32 backend, but Pango uses 1/1024 pt as a 'Pango Unit', and defines PANGO_SCALE to simplify converting points to Pango units. Pango uses Pango units except when it doesn't; e.g. for font sizes. Unfortunately, the Pango functions just use 'int' for all dimensions rather than defining a type for Pango units. (Actually, PangoGlyphUnit is defined in pango-glyph.h but is mostly only used in doc comments.) > I can see two solutions to this: > > 1. All pango-backends compatible with xmlroff must use pt as a unit. > > 2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from > pango-device-units to xmlroff-device-units. Or: 3. Require the child types of FoDoc (wish I had a better name for it) to handle the conversion from points (i.e., xmlroff units) to Pango backend units. For example, the current fo_doc_pdflib_render_layout() code does the multiplication by PANGO_SCALE to convert xmlroff units to Pango units. And, having complained about Pango, it now seems that xmlroff should define and use a typedef for xmlroff units to save people from repeating your confusion. > 1. will loose precision and will not be compatible with: > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit > > 2. seems the way to do it. I don't know if there is an API in pango that lets > you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' > etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo. In theory, the FT2 backend requires you to specify the resolution when creating a PangoContext (or a PangoFT2Context), but the call to FT_Set_Char_Size() in pangoft2.c shows that the resolution isn't really used. Also, the XSL Recommendation errata says that 1 px = 1/96 inch. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Tony G. <Ton...@Su...> - 2003-04-29 16:51:34
|
Tony Graham wrote at 29 Apr 2003 17:48:39 +0100: > Jesper Stigberg wrote at 25 Apr 2003 16:50:25 +0200: > > Sorry for the late reply. ... > > Tony Graham wrote: ... > > > Now that none of area-to-pdf uses PDFlib, it is also possible to break > > > up area-to-pdf and put each area type's code into the area type's > > > implementation of the currently unused 'draw' function of FoArea. > > > > Is this something you are planning todo in the nearest future? > > It's actually something that I've wanted to do for a long time but haven't I meant to say that I intend to write the pangogp version of FoDoc first. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Jesper S. <je...@no...> - 2003-04-30 11:58:27
|
Tony Graham wrote: .... > > > > *** If I understand xmlroff correctly you are using pt as 'device-unit'. This > > works ok when using pangopdflib since it too (I assume) use pt as > > unit, but my pango-win32 backend use pixel as unit. The result of > > this is that all lengths/widths/heights are sometimes measured in > > pixel (when they are 'received' from pango) and sometimes in > > pt. It's not possible to know when to convert from pt to px and > > when not to do it. > > Yes, xmlroff uses pt as the 'device-unit'; i.e., it converts all > dimensions in the FO expressions into points. > > I haven't looked at the Pango Win32 backend, but Pango uses 1/1024 pt > as a 'Pango Unit', and defines PANGO_SCALE to simplify converting > points to Pango units. I think that this is the problem. From: http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit "...The PangoGlyphUnit type is used to store dimensions within Pango. Dimensions are stored in 1/PANGO_SCALE of a device unit. (A device unit might be a pixel for screen display, or a point on a printer.)..." note the "...(A device unit might be a pixel for screen display, or a point on a printer.)..." i.e. a 'device-unit' may be a pt, but it does not have to. >Pango uses Pango units except when it doesn't; > e.g. for font sizes. Unfortunately, the Pango functions just use > 'int' for all dimensions rather than defining a type for Pango units. > (Actually, PangoGlyphUnit is defined in pango-glyph.h but is mostly > only used in doc comments.) > > > I can see two solutions to this: > > > > 1. All pango-backends compatible with xmlroff must use pt as a unit. > > > > 2. Use a 'scale' in xmlroff to convert to pango-device-units, or convert from > > pango-device-units to xmlroff-device-units. > > Or: > > 3. Require the child types of FoDoc (wish I had a better name for it) > to handle the conversion from points (i.e., xmlroff units) to > Pango backend units. I don't think this will work. Consider this snippet from fo-block-area.c: void fo_block_area_new(...) { ... pango_layout_get_extents (pango_layout, NULL, &logical); fo_area_area_set_height (*new_area, logical.height / PANGO_SCALE + border_before_width + padding_before + border_after_width + padding_after); ... } If the pango version in use uses pt as 'device-unit', all is fine. But if it uses another unit we have a mix of units. > For example, the current fo_doc_pdflib_render_layout() code does > the multiplication by PANGO_SCALE to convert xmlroff units to Pango > units. > > And, having complained about Pango, it now seems that xmlroff > should define and use a typedef for xmlroff units to save people > from repeating your confusion. > > > 1. will loose precision and will not be compatible with: > > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit > > > > 2. seems the way to do it. I don't know if there is an API in pango that lets > > you express the device-unit in a 'known' unit, i.e. 'pango_deviceunit_to_twips' > > etc. If not, the 'scale' has to be set explicit by the 'client' of xmlroff/libfo. > > In theory, the FT2 backend requires you to specify the resolution when > creating a PangoContext (or a PangoFT2Context), but the call to > FT_Set_Char_Size() in pangoft2.c shows that the resolution isn't > really used. > > Also, the XSL Recommendation errata says that 1 px = 1/96 inch. Note that in fo-expr-eval.c pt==px. #define POINT2DEVICE(x) x #define PIXEL2DEVICE(x) x Do you want me to file a bug? Regards, Jesper. |
|
From: Tony G. <Ton...@Su...> - 2003-05-05 22:15:48
|
Jesper Stigberg wrote at 30 Apr 2003 14:01:55 +0200: > Tony Graham wrote: ... > I think that this is the problem. From: > http://developer.gnome.org/doc/API/2.0/pango/pango-Glyph-Storage.html#PangoGlyphUnit > > "...The PangoGlyphUnit type is used to store dimensions within > Pango. Dimensions are stored in 1/PANGO_SCALE of a device unit. (A > device unit might be a pixel for screen display, or a point on a > printer.)..." > > note the "...(A device unit might be a pixel for screen display, or > a point on a printer.)..." i.e. a 'device-unit' may be a pt, but it > does not have to. But a device unit is a point for font sizes: There are PANGO_SCALE Pango units in one device unit (device unit is a point, for font sizes). (See http://developer.gnome.org/doc/API/2.0/pango/pango-Fonts.html#pango-font-description-set-size) ... > If the pango version in use uses pt as 'device-unit', all is > fine. But if it uses another unit we have a mix of units. Which is why so far it has been fine, and why it creates problems for your screen rendering backend. I have started a Wiki page to collect in one place all the possibly differing interpretations of device units from XSL, Pango, and FreeType (although I haven't got to FreeType yet). You are welcome to annotate it. What do you do in your rendering application if you want to scale the rendered image, e.g. reduce it so a whole page appears in the window? ... > > Also, the XSL Recommendation errata says that 1 px = 1/96 inch. Actually, it's a CSS2 erratum (http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html), and the XSL 1.0 erratum removes the size recommendation from the XSL 1.0 Recommendation (so XSL won't be bothered by any future dpi changes in CSS). > Note that in fo-expr-eval.c pt==px. > > #define POINT2DEVICE(x) x > #define PIXEL2DEVICE(x) x > > Do you want me to file a bug? Sure. Note also that the code for fo:external-graphic has wavered about the dpi. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Jesper S. <je...@no...> - 2003-05-08 12:36:36
|
Tony Graham wrote: > Jesper Stigberg wrote at 30 Apr 2003 14:01:55 +0200: > > Tony Graham wrote: > But a device unit is a point for font sizes: > > There are PANGO_SCALE Pango units in one device unit (device unit > is a point, for font sizes). > > (See http://developer.gnome.org/doc/API/2.0/pango/pango-Fonts.html#pango-font-description-set-size) Yes. > .. > > If the pango version in use uses pt as 'device-unit', all is > > fine. But if it uses another unit we have a mix of units. > > Which is why so far it has been fine, and why it creates problems for > your screen rendering backend. > Yup. > I have started a Wiki page to collect in one place all the possibly > differing interpretations of device units from XSL, Pango, and > FreeType (although I haven't got to FreeType yet). You are welcome to > annotate it. Great. What do gnome-print use as a unit? > What do you do in your rendering application if you want to scale the > rendered image, e.g. reduce it so a whole page appears in the window? > A bit simplified. In the win32 GDI (graphics device interface), all drawing, text-output etc is done through a device-context using logical-units. What appears on the screen is measured in device-units. A device-unit==scale*logical-unit ( this mapping is done by the OS ). So by changing the scale you can get a zoom effect without changing the coordinates etc in your drawing code, or use the same code to render to a printer. > .. > > > Also, the XSL Recommendation errata says that 1 px = 1/96 inch. > > Actually, it's a CSS2 erratum > (http://www.w3.org/Style/css2-updates/REC-CSS2-19980512-errata.html), > and the XSL 1.0 erratum removes the size recommendation from the XSL > 1.0 Recommendation (so XSL won't be bothered by any future dpi changes > in CSS). > > > Note that in fo-expr-eval.c pt==px. > > > > #define POINT2DEVICE(x) x > > #define PIXEL2DEVICE(x) x > > > > Do you want me to file a bug? > > Sure. Note also that the code for fo:external-graphic has wavered > about the dpi. Noted. Regards, Jesper. |
|
From: Tony G. <Ton...@Su...> - 2003-05-08 16:46:42
|
Jesper Stigberg wrote at 8 May 2003 14:39:29 +0200: > Tony Graham wrote: ... > > I have started a Wiki page to collect in one place all the possibly > > differing interpretations of device units from XSL, Pango, and > > FreeType (although I haven't got to FreeType yet). You are welcome to > > annotate it. > > Great. What do gnome-print use as a unit? So far I've found that the PDF and PostScript outputs use different units. GNOME Print is under-documented, so there may be something that I'm missing. See pangogp-to-pdf.c in pangopdf/examples. > > What do you do in your rendering application if you want to scale the > > rendered image, e.g. reduce it so a whole page appears in the window? > > > > A bit simplified. > > In the win32 GDI (graphics device interface), all drawing, > text-output etc is done through a device-context using > logical-units. What appears on the screen is measured in > device-units. A device-unit==scale*logical-unit ( this mapping is > done by the OS ). So by changing the scale you can get a zoom > effect without changing the coordinates etc in your drawing code, > or use the same code to render to a printer. And the logical unit is a 'twip', i.e., a logical pixel? Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
|
From: Jesper S. <je...@no...> - 2003-05-09 00:19:43
|
Tony Graham wrote: > Jesper Stigberg wrote at 8 May 2003 14:39:29 +0200: .... > > Great. What do gnome-print use as a unit? > > So far I've found that the PDF and PostScript outputs use different > units. GNOME Print is under-documented, so there may be something > that I'm missing. > > See pangogp-to-pdf.c in pangopdf/examples. > > > > What do you do in your rendering application if you want to scale the > > > rendered image, e.g. reduce it so a whole page appears in the window? > > > > > > > A bit simplified. > > > > In the win32 GDI (graphics device interface), all drawing, > > text-output etc is done through a device-context using > > logical-units. What appears on the screen is measured in > > device-units. A device-unit==scale*logical-unit ( this mapping is > > done by the OS ). So by changing the scale you can get a zoom > > effect without changing the coordinates etc in your drawing code, > > or use the same code to render to a printer. > > And the logical unit is a 'twip', i.e., a logical pixel? A logical unit can be mapped to twips, pixels, mm, etc or a unit of your own. ex: move_to(0,0); /* (x,y), in logical units */ line_to(0,20); this could draw a 20 pixel or a 20 twips long line, depending on what a logical unit is mapped to. I don't know what a logical pixel is, a twip is, as far as I know, 1/1440 of an inch. Jesper. |
|
From: Tony G. <Ton...@Su...> - 2003-05-26 15:12:11
|
Sorry for the delay, but I've been busy with GNOME Print (and with the non-xmlroff part of my job). Jesper Stigberg wrote at 8 May 2003 22:15:28 +0200: > Tony Graham wrote: > > Jesper Stigberg wrote at 8 May 2003 14:39:29 +0200: ... > > > In the win32 GDI (graphics device interface), all drawing, > > > text-output etc is done through a device-context using > > > logical-units. What appears on the screen is measured in > > > device-units. A device-unit==scale*logical-unit ( this mapping is > > > done by the OS ). So by changing the scale you can get a zoom > > > effect without changing the coordinates etc in your drawing code, > > > or use the same code to render to a printer. > > > > And the logical unit is a 'twip', i.e., a logical pixel? > > A logical unit can be mapped to twips, pixels, mm, etc or a unit of > your own. > > ex: > move_to(0,0); /* (x,y), in logical units */ > line_to(0,20); > > this could draw a 20 pixel or a 20 twips long line, depending on > what a logical unit is mapped to. So what, then, is the problem with using points as the logical unit? (I'm not decreeing that you have to use points, I'm just trying to sort out the implications.) > I don't know what a logical pixel is, a twip is, as far as I know, > 1/1440 of an inch. That's what I get for dashing off a reply. I meant that a twip is not actually the resolution of your display but some known small distance that is convenient for computation. Rather like a Pango unit, I suppose, although it's the rubbery nature of Pango units that's causing the current exchange. Regards, Tony Graham ------------------------------------------------------------------------ XML Technology Center - Dublin Sun Microsystems Ireland Ltd Phone: +353 1 8199708 Hamilton House, East Point Business Park, Dublin 3 x(70)19708 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X