Re: Export to RTF

Hi Allen

You won't like the look of the SQL

SELECT QMemAdd.MemSurName, QMemAdd.MemFirstName, QMemAdd.MemAddID,
QMemAdd.MemPhone, QMemAdd.MemMobile, QMemAdd.MemEMail,
QSubMembersBoats.BoatName, QSubMembersBoats.BoatClass,
QMemAdd.lstAddress.MemAdd, QMemAdd.MemStatID
FROM QSubMembersBoats RIGHT JOIN QMemAdd ON QSubMembersBoats.MemberID =
QMemAdd.MemberID
WHERE (((QMemAdd.NotInAddressBook)=False));

SELECT DISTINCTROW Member.*,
Round((IIf([MemRetiredID]<2,IIf((Now()<=[Year]![InArrears]) Or
(([LastPayDate]>=[Year]![YearStart]) And
([LastPayDate]<=[Year]![InArrears])),[FeesDue],[LateFees]),0))*(1-[MemFeeDisc]),2)
AS MemFees,
Round((IIf([MemRetiredID]<2,IIf([MemJoinDate]> =[Year]![YearStart],[JoiningFee],0),0))*(1-[MemJoinFeeDisc]) ,2)
AS JoinFee, [MemFees]+[JoinFee] AS TotFees, lstAddress.MemAdd1,
lstAddress.MemAdd2, lstAddress.MemAdd3, lstAddress.TownID, lstAddress.Town,
lstAddress.County, lstAddress.PostCode, lstAddress.Country,
lstAddress.STDCode, lstAddress.MemAdd, lstAddress.MemAddLF,
LstAddress_1.MemAdd, LstAddress_1.MemAddLF, LstAddress_1.SecondPhone,
LstAddress_1.SecondMobile, LstAddress_1.SecondEMail,
MemClass.Classification, MemStat.MemStatDesc,
EMax("PaymentDate","Payments","MemberID = " & [Member]![MemberID]) AS
LastPayDate
FROM [Year] INNER JOIN (tblJoiningFees INNER JOIN (MemClass INNER JOIN
(MemStat INNER JOIN (((Member INNER JOIN lstAddress ON Member.MemAddID =
lstAddress.MemAddID) LEFT JOIN LstAddress AS LstAddress_1 ON
Member.MemAddID2 = LstAddress_1.MemAddID) LEFT JOIN Town ON
LstAddress_1.TownID = Town.TownID) ON MemStat.MemStatID = Member.MemStatID)
ON MemClass.MemClassID = Member.MemClassID) ON tblJoiningFees.JoiningFeesID
= MemClass.JoiningFeesID) ON Year.YearID = Member.YearID
WHERE
(((Member.MemRetiredID)=IIf([Year]![MemActivity]=0,[Member]. [MemRetiredID],[Year]![MemActivity])))
ORDER BY Member.MemSurName, Member.MemAddID, Member.MemFirstName
WITH OWNERACCESS OPTION;


Actually I don't think it is relevant.

One of the fields that gets cut off is QSubMembersBoats.BoatName (Text,
Field Size = 25 characters), another is QMemAdd.MemPhone Text, FieldSize =
24)

The program and data have been copied from my machine to both the laptop and
Yacht Club machine. The printer defaults (don't know if they are relevant)
are the same for the laptop and my machine, but different for the Club
Machine. Another odd thing, again don't know it's relevance, is that the
report is set up to print on A6 paper. When I open it up on the laptop it is
printing on A4. I am producinf a Club Diectory of members and the print size
is Arial 6.

Thanks again for your interest

Phil


"Allen Browne" wrote in message
news:47677d61$0$20626$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
> Text fields? Concatenated to more than 255 char?
> Or truncating shorter than that?
>
> Post the SQL statement, indicating the field types and sizes involved in
> the concatenation. Something else must be going on.
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> "Phil Stanton" wrote in message
> news:13mev69ljrr0ub9@corp.supernews.com...
>> Thanks for coming back, Allen
>>
>> Curiouser and curiouser - the fields being truncated are ordinary text
>> fields, in particular, phone nos and boat names.
>> What is really odd that is on my machine at home, running XP there is no
>> problem. The problem shows up on both my laptop running XP and also with
>> the computer at the Yacht Club running Windows 2000.
>>
>> Any other thoughts
>>
>> Thanks
>>
>> Phil
>>
>> "Allen Browne" wrote in message
>> news:47672172$0$20632$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>>> Phil, there has always been problems with fields being truncated at 255
>>> chars when exported to RTF.
>>>
>>> From memory, I don't think MS has fixed all these issues. The kb
>>> articles that discuss them are listed here:
>>> Truncation of Memo fields
>>> at:
>>> http://allenbrowne.com/ser-63.html
>>>
>>> Scroll down to the "Exports" heading.
>>>
>>> "News" wrote in message
>>> news:4766ba69$1_1@mk-nntp-2.news.uk.tiscali.com...
>>>> Am having a problem usink AK2 exporting a report to an RTF file. The
>>>> Access report has most fields and sections set to CanShrink and
>>>> CanGrow. The report looks fine, but the ends of a number of fields get
>>>> cropped. Can export to a PDF file OK, but I can't edit a PDF file.
>

Re: Export to RTF

The truncation that happens when exporting to RTF has nothing to do with the
data type and is a completely different matter from the truncation of memo
fields seen in other situations.

It happens because the export to RTF feature is flawed. It has had this problem
since at least Access 95 and it has never been fixed and likely never will be.
At its roots are differences is font kerning, spacing, etc, between Access and
Word that cause text snippets to take up more horizontal space in Word than they
do in Access. This combined with soft line-wrapping rules and various other
factors cause the problem.

The solution is to NOT use the RTF option for anything but very simple tabular
data that does need CanGrow and CanShrink capabilities. Even then you need to
make many of your controls in the report wider than would otherwise be required.

You can fiddle around with the design of your report using your current data and
perhaps convince yourself that you have corrected the problem. That will be an
illusion. Once your data changes the problem will resurface.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Re: Export to RTF

Thanks Rick.

Any thoughts on why the export is fine on 1 computer and truncated on the
other 2 machines, all running Office 2000?

Phil

"Rick Brandt" wrote in message
news:PTT9j.15$pA7.8@newssvr25.news.prodigy.net...
> The truncation that happens when exporting to RTF has nothing to do with
> the data type and is a completely different matter from the truncation of
> memo fields seen in other situations.
>
> It happens because the export to RTF feature is flawed. It has had this
> problem since at least Access 95 and it has never been fixed and likely
> never will be. At its roots are differences is font kerning, spacing, etc,
> between Access and Word that cause text snippets to take up more
> horizontal space in Word than they do in Access. This combined with soft
> line-wrapping rules and various other factors cause the problem.
>
> The solution is to NOT use the RTF option for anything but very simple
> tabular data that does need CanGrow and CanShrink capabilities. Even then
> you need to make many of your controls in the report wider than would
> otherwise be required.
>
> You can fiddle around with the design of your report using your current
> data and perhaps convince yourself that you have corrected the problem.
> That will be an illusion. Once your data changes the problem will
> resurface.
>
> --
> Rick Brandt, Microsoft Access MVP
> Email (as appropriate) to...
> RBrandt at Hunter dot com
>
>
>

Re: Export to RTF

Your top level query draws from 2 lower-level queries, so we don't know what
the source of BoatName is. I take it that it is not a concatenated field
(i.e. it is a Text field, size 25, in some table.)

Perhaps there's something in the other query that's confusing JET. Nothing
obvious jumps out here.

One possibility is that the machine that gives the wrong answer has a
different version of JET 4. Assuming this is Access 2000, 2002, 2003, find
msjet40.dll (typically in windows\system32), right-click and see if its
Properties indicate it is the same version. If the minor version is less
than 8 (e.g. 4.0.8xxx), that machine needs a JET service pack from
http://support.microsoft.com/sp

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Phil Stanton" wrote in message
news:13mg1fibu7p2ta0@corp.supernews.com...
> Hi Allen
>
> You won't like the look of the SQL
>
> SELECT QMemAdd.MemSurName, QMemAdd.MemFirstName, QMemAdd.MemAddID,
> QMemAdd.MemPhone, QMemAdd.MemMobile, QMemAdd.MemEMail,
> QSubMembersBoats.BoatName, QSubMembersBoats.BoatClass,
> QMemAdd.lstAddress.MemAdd, QMemAdd.MemStatID
> FROM QSubMembersBoats RIGHT JOIN QMemAdd ON QSubMembersBoats.MemberID =
> QMemAdd.MemberID
> WHERE (((QMemAdd.NotInAddressBook)=False));
>
> SELECT DISTINCTROW Member.*,
> Round((IIf([MemRetiredID]<2,IIf((Now()<=[Year]![InArrears]) Or
> (([LastPayDate]>=[Year]![YearStart]) And
> ([LastPayDate]<=[Year]![InArrears])),[FeesDue],[LateFees]),0))*(1-[MemFeeDisc]),2)
> AS MemFees,
> Round((IIf([MemRetiredID]<2,IIf([MemJoinDate]> =[Year]![YearStart],[JoiningFee],0),0))*(1-[MemJoinFeeDisc]) ,2)
> AS JoinFee, [MemFees]+[JoinFee] AS TotFees, lstAddress.MemAdd1,
> lstAddress.MemAdd2, lstAddress.MemAdd3, lstAddress.TownID,
> lstAddress.Town, lstAddress.County, lstAddress.PostCode,
> lstAddress.Country, lstAddress.STDCode, lstAddress.MemAdd,
> lstAddress.MemAddLF, LstAddress_1.MemAdd, LstAddress_1.MemAddLF,
> LstAddress_1.SecondPhone, LstAddress_1.SecondMobile,
> LstAddress_1.SecondEMail, MemClass.Classification, MemStat.MemStatDesc,
> EMax("PaymentDate","Payments","MemberID = " & [Member]![MemberID]) AS
> LastPayDate
> FROM [Year] INNER JOIN (tblJoiningFees INNER JOIN (MemClass INNER JOIN
> (MemStat INNER JOIN (((Member INNER JOIN lstAddress ON Member.MemAddID =
> lstAddress.MemAddID) LEFT JOIN LstAddress AS LstAddress_1 ON
> Member.MemAddID2 = LstAddress_1.MemAddID) LEFT JOIN Town ON
> LstAddress_1.TownID = Town.TownID) ON MemStat.MemStatID =
> Member.MemStatID) ON MemClass.MemClassID = Member.MemClassID) ON
> tblJoiningFees.JoiningFeesID = MemClass.JoiningFeesID) ON Year.YearID =
> Member.YearID
> WHERE
> (((Member.MemRetiredID)=IIf([Year]![MemActivity]=0,[Member]. [MemRetiredID],[Year]![MemActivity])))
> ORDER BY Member.MemSurName, Member.MemAddID, Member.MemFirstName
> WITH OWNERACCESS OPTION;
>
>
> Actually I don't think it is relevant.
>
> One of the fields that gets cut off is QSubMembersBoats.BoatName (Text,
> Field Size = 25 characters), another is QMemAdd.MemPhone Text, FieldSize =
> 24)
>
> The program and data have been copied from my machine to both the laptop
> and Yacht Club machine. The printer defaults (don't know if they are
> relevant) are the same for the laptop and my machine, but different for
> the Club Machine. Another odd thing, again don't know it's relevance, is
> that the report is set up to print on A6 paper. When I open it up on the
> laptop it is printing on A4. I am producinf a Club Diectory of members and
> the print size is Arial 6.
>
> Thanks again for your interest
>
> Phil
>
>
> "Allen Browne" wrote in message
> news:47677d61$0$20626$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>> Text fields? Concatenated to more than 255 char?
>> Or truncating shorter than that?
>>
>> Post the SQL statement, indicating the field types and sizes involved in
>> the concatenation. Something else must be going on.
>>
>> "Phil Stanton" wrote in message
>> news:13mev69ljrr0ub9@corp.supernews.com...
>>> Thanks for coming back, Allen
>>>
>>> Curiouser and curiouser - the fields being truncated are ordinary text
>>> fields, in particular, phone nos and boat names.
>>> What is really odd that is on my machine at home, running XP there is no
>>> problem. The problem shows up on both my laptop running XP and also with
>>> the computer at the Yacht Club running Windows 2000.
>>>
>>> Any other thoughts
>>>
>>> Thanks
>>>
>>> Phil
>>>
>>> "Allen Browne" wrote in message
>>> news:47672172$0$20632$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>>>> Phil, there has always been problems with fields being truncated at 255
>>>> chars when exported to RTF.
>>>>
>>>> From memory, I don't think MS has fixed all these issues. The kb
>>>> articles that discuss them are listed here:
>>>> Truncation of Memo fields
>>>> at:
>>>> http://allenbrowne.com/ser-63.html
>>>>
>>>> Scroll down to the "Exports" heading.
>>>>
>>>> "News" wrote in message
>>>> news:4766ba69$1_1@mk-nntp-2.news.uk.tiscali.com...
>>>>> Am having a problem usink AK2 exporting a report to an RTF file. The
>>>>> Access report has most fields and sections set to CanShrink and
>>>>> CanGrow. The report looks fine, but the ends of a number of fields get
>>>>> cropped. Can export to a PDF file OK, but I can't edit a PDF file.

Re: Export to RTF

Phil Stanton wrote:
> Thanks Rick.
>
> Any thoughts on why the export is fine on 1 computer and truncated on
> the other 2 machines, all running Office 2000?

The problem is influenced by your default printer driver and perhaps other
settings in Word and/or Access.
--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Re: Export to RTF

Thanks Allen & Rick

BoatName is a field defined in the Boat table - no messing about with it al
all

MSJET40 version is 4.0.8618.0 on both machines. However as the report is
perfectly OK in access, the problem would appear to be in whatever bit of
software converts the access report to an RTF file. Is there a DLL that
does this or is it done by MSJET40. I had a sort of feeling that there would
be a "program" invoked to covert to an RTF file, a different "program" to
convert to Excel etc.

Will also recheck settings. Again any suggestion on which ones

Thanks again

Phil

"Allen Browne" wrote in message
news:476859de$0$20647$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
> Your top level query draws from 2 lower-level queries, so we don't know
> what the source of BoatName is. I take it that it is not a concatenated
> field (i.e. it is a Text field, size 25, in some table.)
>
> Perhaps there's something in the other query that's confusing JET. Nothing
> obvious jumps out here.
>
> One possibility is that the machine that gives the wrong answer has a
> different version of JET 4. Assuming this is Access 2000, 2002, 2003, find
> msjet40.dll (typically in windows\system32), right-click and see if its
> Properties indicate it is the same version. If the minor version is less
> than 8 (e.g. 4.0.8xxx), that machine needs a JET service pack from
> http://support.microsoft.com/sp
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> "Phil Stanton" wrote in message
> news:13mg1fibu7p2ta0@corp.supernews.com...
>> Hi Allen
>>
>> You won't like the look of the SQL
>>
>> SELECT QMemAdd.MemSurName, QMemAdd.MemFirstName, QMemAdd.MemAddID,
>> QMemAdd.MemPhone, QMemAdd.MemMobile, QMemAdd.MemEMail,
>> QSubMembersBoats.BoatName, QSubMembersBoats.BoatClass,
>> QMemAdd.lstAddress.MemAdd, QMemAdd.MemStatID
>> FROM QSubMembersBoats RIGHT JOIN QMemAdd ON QSubMembersBoats.MemberID =
>> QMemAdd.MemberID
>> WHERE (((QMemAdd.NotInAddressBook)=False));
>>
>> SELECT DISTINCTROW Member.*,
>> Round((IIf([MemRetiredID]<2,IIf((Now()<=[Year]![InArrears]) Or
>> (([LastPayDate]>=[Year]![YearStart]) And
>> ([LastPayDate]<=[Year]![InArrears])),[FeesDue],[LateFees]),0))*(1-[MemFeeDisc]),2)
>> AS MemFees,
>> Round((IIf([MemRetiredID]<2,IIf([MemJoinDate]> =[Year]![YearStart],[JoiningFee],0),0))*(1-[MemJoinFeeDisc]) ,2)
>> AS JoinFee, [MemFees]+[JoinFee] AS TotFees, lstAddress.MemAdd1,
>> lstAddress.MemAdd2, lstAddress.MemAdd3, lstAddress.TownID,
>> lstAddress.Town, lstAddress.County, lstAddress.PostCode,
>> lstAddress.Country, lstAddress.STDCode, lstAddress.MemAdd,
>> lstAddress.MemAddLF, LstAddress_1.MemAdd, LstAddress_1.MemAddLF,
>> LstAddress_1.SecondPhone, LstAddress_1.SecondMobile,
>> LstAddress_1.SecondEMail, MemClass.Classification, MemStat.MemStatDesc,
>> EMax("PaymentDate","Payments","MemberID = " & [Member]![MemberID]) AS
>> LastPayDate
>> FROM [Year] INNER JOIN (tblJoiningFees INNER JOIN (MemClass INNER JOIN
>> (MemStat INNER JOIN (((Member INNER JOIN lstAddress ON Member.MemAddID =
>> lstAddress.MemAddID) LEFT JOIN LstAddress AS LstAddress_1 ON
>> Member.MemAddID2 = LstAddress_1.MemAddID) LEFT JOIN Town ON
>> LstAddress_1.TownID = Town.TownID) ON MemStat.MemStatID =
>> Member.MemStatID) ON MemClass.MemClassID = Member.MemClassID) ON
>> tblJoiningFees.JoiningFeesID = MemClass.JoiningFeesID) ON Year.YearID =
>> Member.YearID
>> WHERE
>> (((Member.MemRetiredID)=IIf([Year]![MemActivity]=0,[Member]. [MemRetiredID],[Year]![MemActivity])))
>> ORDER BY Member.MemSurName, Member.MemAddID, Member.MemFirstName
>> WITH OWNERACCESS OPTION;
>>
>>
>> Actually I don't think it is relevant.
>>
>> One of the fields that gets cut off is QSubMembersBoats.BoatName (Text,
>> Field Size = 25 characters), another is QMemAdd.MemPhone Text, FieldSize
>> = 24)
>>
>> The program and data have been copied from my machine to both the laptop
>> and Yacht Club machine. The printer defaults (don't know if they are
>> relevant) are the same for the laptop and my machine, but different for
>> the Club Machine. Another odd thing, again don't know it's relevance, is
>> that the report is set up to print on A6 paper. When I open it up on the
>> laptop it is printing on A4. I am producinf a Club Diectory of members
>> and the print size is Arial 6.
>>
>> Thanks again for your interest
>>
>> Phil
>>
>>
>> "Allen Browne" wrote in message
>> news:47677d61$0$20626$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>>> Text fields? Concatenated to more than 255 char?
>>> Or truncating shorter than that?
>>>
>>> Post the SQL statement, indicating the field types and sizes involved in
>>> the concatenation. Something else must be going on.
>>>
>>> "Phil Stanton" wrote in message
>>> news:13mev69ljrr0ub9@corp.supernews.com...
>>>> Thanks for coming back, Allen
>>>>
>>>> Curiouser and curiouser - the fields being truncated are ordinary text
>>>> fields, in particular, phone nos and boat names.
>>>> What is really odd that is on my machine at home, running XP there is
>>>> no problem. The problem shows up on both my laptop running XP and also
>>>> with the computer at the Yacht Club running Windows 2000.
>>>>
>>>> Any other thoughts
>>>>
>>>> Thanks
>>>>
>>>> Phil
>>>>
>>>> "Allen Browne" wrote in message
>>>> news:47672172$0$20632$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>>>>> Phil, there has always been problems with fields being truncated at
>>>>> 255 chars when exported to RTF.
>>>>>
>>>>> From memory, I don't think MS has fixed all these issues. The kb
>>>>> articles that discuss them are listed here:
>>>>> Truncation of Memo fields
>>>>> at:
>>>>> http://allenbrowne.com/ser-63.html
>>>>>
>>>>> Scroll down to the "Exports" heading.
>>>>>
>>>>> "News" wrote in message
>>>>> news:4766ba69$1_1@mk-nntp-2.news.uk.tiscali.com...
>>>>>> Am having a problem usink AK2 exporting a report to an RTF file. The
>>>>>> Access report has most fields and sections set to CanShrink and
>>>>>> CanGrow. The report looks fine, but the ends of a number of fields
>>>>>> get cropped. Can export to a PDF file OK, but I can't edit a PDF
>>>>>> file.
>

Re: Export to RTF

That's fair enough, Phil.

Off the top of my head, I can't tell you which lib does the exporting.
Perhaps you could start by just checking whether it's the same Office
service pack.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Phil Stanton" wrote in message
news:13mhl0v5o4fhs31@corp.supernews.com...
> Thanks Allen & Rick
>
> BoatName is a field defined in the Boat table - no messing about with it
> al all
>
> MSJET40 version is 4.0.8618.0 on both machines. However as the report is
> perfectly OK in access, the problem would appear to be in whatever bit of
> software converts the access report to an RTF file. Is there a DLL that
> does this or is it done by MSJET40. I had a sort of feeling that there
> would be a "program" invoked to covert to an RTF file, a different
> "program" to convert to Excel etc.
>
> Will also recheck settings. Again any suggestion on which ones

Re: Export to RTF

Been playing further. Cant find any differences in settings. If however I
change the font from Arial to Arial Narrow and then export the report, the
RTF file is OK. Trouble is that I am already using 6 point Arial which is
just about readable. 6 point Arial narrow is very difficult to read.

Phil


"Allen Browne" wrote in message
news:4768fabc$0$20652$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
> That's fair enough, Phil.
>
> Off the top of my head, I can't tell you which lib does the exporting.
> Perhaps you could start by just checking whether it's the same Office
> service pack.
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> "Phil Stanton" wrote in message
> news:13mhl0v5o4fhs31@corp.supernews.com...
>> Thanks Allen & Rick
>>
>> BoatName is a field defined in the Boat table - no messing about with it
>> al all
>>
>> MSJET40 version is 4.0.8618.0 on both machines. However as the report is
>> perfectly OK in access, the problem would appear to be in whatever bit of
>> software converts the access report to an RTF file. Is there a DLL that
>> does this or is it done by MSJET40. I had a sort of feeling that there
>> would be a "program" invoked to covert to an RTF file, a different
>> "program" to convert to Excel etc.
>>
>> Will also recheck settings. Again any suggestion on which ones
>

Re: Export to RTF

It's an issue with font metrics???

What happens if you use Arial CYR?

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"Phil Stanton" wrote in message
news:13mobvqksmf3p9e@corp.supernews.com...
> Been playing further. Cant find any differences in settings. If however I
> change the font from Arial to Arial Narrow and then export the report, the
> RTF file is OK. Trouble is that I am already using 6 point Arial which is
> just about readable. 6 point Arial narrow is very difficult to read.
>
> Phil
>
>
> "Allen Browne" wrote in message
> news:4768fabc$0$20652$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>> That's fair enough, Phil.
>>
>> Off the top of my head, I can't tell you which lib does the exporting.
>> Perhaps you could start by just checking whether it's the same Office
>> service pack.
>>
>> "Phil Stanton" wrote in message
>> news:13mhl0v5o4fhs31@corp.supernews.com...
>>> Thanks Allen & Rick
>>>
>>> BoatName is a field defined in the Boat table - no messing about with it
>>> al all
>>>
>>> MSJET40 version is 4.0.8618.0 on both machines. However as the report is
>>> perfectly OK in access, the problem would appear to be in whatever bit
>>> of software converts the access report to an RTF file. Is there a DLL
>>> that does this or is it done by MSJET40. I had a sort of feeling that
>>> there would be a "program" invoked to covert to an RTF file, a different
>>> "program" to convert to Excel etc.
>>>
>>> Will also recheck settings. Again any suggestion on which ones

Re: Export to RTF

Phil Stanton wrote:
> Been playing further. Cant find any differences in settings. If
> however I change the font from Arial to Arial Narrow and then export
> the report, the RTF file is OK. Trouble is that I am already using 6
> point Arial which is just about readable. 6 point Arial narrow is
> very difficult to read.

But as I stated before... no matter what you do to make your current report with
your current data look correct if this is a dynamic report that will use
different data over time or per-filter settings then you will still see the
problem as your data changes.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Re: Export to RTF

Change of font had no effect.

Have partially resolved the problem though.
The original report is on A6 paper, width 105mm with left and right margins
set at 6mm. The report grid size is 10 both ways. I am using snap to grid.
The 2 fields where I am having problems left position is 77.99 ( why with
snap to grid it is not 78 I have no idea) and the width is 15.01 which all
adds up OK. This is the layout of the report that works on my main machine,
but not the laptop.

If I pull the margins down to 5.7 and increase the field width to 15.52
(guess I better change the grid to 20) works OK on both machines. Any wider
margins or narrower field size won't export correctly on my laptop. All very
odd

Thanks for all your help to both Allen and Rick

Phil

"Allen Browne" wrote in message
news:476c53db$0$14131$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
> It's an issue with font metrics???
>
> What happens if you use Arial CYR?
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> "Phil Stanton" wrote in message
> news:13mobvqksmf3p9e@corp.supernews.com...
>> Been playing further. Cant find any differences in settings. If however I
>> change the font from Arial to Arial Narrow and then export the report,
>> the RTF file is OK. Trouble is that I am already using 6 point Arial
>> which is just about readable. 6 point Arial narrow is very difficult to
>> read.
>>
>> Phil
>>
>>
>> "Allen Browne" wrote in message
>> news:4768fabc$0$20652$5a62ac22@per-qv1-newsreader-01.iinet.n et.au...
>>> That's fair enough, Phil.
>>>
>>> Off the top of my head, I can't tell you which lib does the exporting.
>>> Perhaps you could start by just checking whether it's the same Office
>>> service pack.
>>>
>>> "Phil Stanton" wrote in message
>>> news:13mhl0v5o4fhs31@corp.supernews.com...
>>>> Thanks Allen & Rick
>>>>
>>>> BoatName is a field defined in the Boat table - no messing about with
>>>> it al all
>>>>
>>>> MSJET40 version is 4.0.8618.0 on both machines. However as the report
>>>> is perfectly OK in access, the problem would appear to be in whatever
>>>> bit of software converts the access report to an RTF file. Is there a
>>>> DLL that does this or is it done by MSJET40. I had a sort of feeling
>>>> that there would be a "program" invoked to covert to an RTF file, a
>>>> different "program" to convert to Excel etc.
>>>>
>>>> Will also recheck settings. Again any suggestion on which ones
>

Re: Export to RTF

"Phil Stanton" wrote in
news:13mpolnqj2necea@corp.supernews.com:

> Change of font had no effect.
>
> Have partially resolved the problem though.
> The original report is on A6 paper, width 105mm with left and right
> margins set at 6mm. The report grid size is 10 both ways. I am using
> snap to grid. The 2 fields where I am having problems left position is
> 77.99 ( why with snap to grid it is not 78 I have no idea) and the
> width is 15.01 which all adds up OK. This is the layout of the report
> that works on my main machine, but not the laptop.
>
> If I pull the margins down to 5.7 and increase the field width to
> 15.52 (guess I better change the grid to 20) works OK on both
> machines. Any wider margins or narrower field size won't export
> correctly on my laptop. All very odd

I think this might address the problem that maybe you're identifying ...
maybe ... perhaps.
What it tries to do is set all control locations and sizes to an exact
number of pixels for your set up.

I expect I don't have to remind you to try it (if you are going to try it)
on a throw way copy, but I'll include the warning for anyone else who might
be reading this.

Of course, you'll see and have to repair extra line feeds introduced by
news clients.

Private Declare Function GetDC& Lib "user32" _
(ByVal windowHandle&)
Private Declare Function ReleaseDC& Lib "user32" _
(ByVal windowHandle&, ByVal WindowDeviceHandle&)
Private Declare Function GetDeviceCaps& Lib "gdi32" _
(ByVal windowHandle&, ByVal Index&)

Private Const LOGPIXELSX& = &H5A
Private Const LOGPIXELSY& = &H5A
Private Const TWIPSPERINCH& = 1440

Public Sub StandardizeControlDimensions(ByVal ReportName$)
Dim rpt As Report
Dim ctl As Control
Dim aTwipsPerPixel As Variant
aTwipsPerPixel = TwipsPerPixel()
On Error GoTo StandardizeControlDimensionsErr
Echo 0
DoCmd.OpenReport ReportName, acDesign
Set rpt = Reports(ReportName)
For Each ctl In rpt.Controls
ctl.Height = (Round(ctl.Height / aTwipsPerPixel(1), 0) * aTwipsPerPixel
(1))
ctl.Width = Round(ctl.Width / aTwipsPerPixel(0), 0) * aTwipsPerPixel(0)
Next ctl
StandardizeControlDimensionsExit:
Echo -1
DoCmd.Close acReport, ReportName, acSaveYes
Exit Sub
StandardizeControlDimensionsErr:
With Err
MsgBox .Description, vbCritical, "Error # " & .Number
End With
Resume StandardizeControlDimensionsExit
End Sub

Public Function TwipsPerPixel()
Dim aTwipsPerPixel$(0 To 1)
Dim DesktopWindow&
Dim DesktopWindowDeviceHandle&
DesktopWindowDeviceHandle = GetDC(DesktopWindow)
aTwipsPerPixel(0) = TWIPSPERINCH \ GetDeviceCaps
(DesktopWindowDeviceHandle, LOGPIXELSX)
aTwipsPerPixel(1) = TWIPSPERINCH \ GetDeviceCaps
(DesktopWindowDeviceHandle, LOGPIXELSY)
ReleaseDC DesktopWindow, DesktopWindowDeviceHandle
TwipsPerPixel = aTwipsPerPixel
End Function

One more time: for anyone thinking of trying this; do it on a throw away
copy of the report, please..

Re: Export to RTF

Interesting thought, Lyle.

All 3 computers are working at different screen resolutions and after
running your code needless to say the widths change. Then I run into all
sorts of problems with overlapping controls. However I guess that your
remarks apply to Access rather than Word (RTF File), and everything is
perfect in the Access reports with the margins at 6 mm and control widths at
15.01. The problem only become apparent after exporting to Word.

Phil


"lyle fairfield" wrote in message
news:AR9bj.631$jU1.269@read1.cgocable.net...
> "Phil Stanton" wrote in
> news:13mpolnqj2necea@corp.supernews.com:
>
>> Change of font had no effect.
>>
>> Have partially resolved the problem though.
>> The original report is on A6 paper, width 105mm with left and right
>> margins set at 6mm. The report grid size is 10 both ways. I am using
>> snap to grid. The 2 fields where I am having problems left position is
>> 77.99 ( why with snap to grid it is not 78 I have no idea) and the
>> width is 15.01 which all adds up OK. This is the layout of the report
>> that works on my main machine, but not the laptop.
>>
>> If I pull the margins down to 5.7 and increase the field width to
>> 15.52 (guess I better change the grid to 20) works OK on both
>> machines. Any wider margins or narrower field size won't export
>> correctly on my laptop. All very odd
>
> I think this might address the problem that maybe you're identifying ...
> maybe ... perhaps.
> What it tries to do is set all control locations and sizes to an exact
> number of pixels for your set up.
>
> I expect I don't have to remind you to try it (if you are going to try it)
> on a throw way copy, but I'll include the warning for anyone else who
> might
> be reading this.
>
> Of course, you'll see and have to repair extra line feeds introduced by
> news clients.
>
> Private Declare Function GetDC& Lib "user32" _
> (ByVal windowHandle&)
> Private Declare Function ReleaseDC& Lib "user32" _
> (ByVal windowHandle&, ByVal WindowDeviceHandle&)
> Private Declare Function GetDeviceCaps& Lib "gdi32" _
> (ByVal windowHandle&, ByVal Index&)
>
> Private Const LOGPIXELSX& = &H5A
> Private Const LOGPIXELSY& = &H5A
> Private Const TWIPSPERINCH& = 1440
>
> Public Sub StandardizeControlDimensions(ByVal ReportName$)
> Dim rpt As Report
> Dim ctl As Control
> Dim aTwipsPerPixel As Variant
> aTwipsPerPixel = TwipsPerPixel()
> On Error GoTo StandardizeControlDimensionsErr
> Echo 0
> DoCmd.OpenReport ReportName, acDesign
> Set rpt = Reports(ReportName)
> For Each ctl In rpt.Controls
> ctl.Height = (Round(ctl.Height / aTwipsPerPixel(1), 0) * aTwipsPerPixel
> (1))
> ctl.Width = Round(ctl.Width / aTwipsPerPixel(0), 0) * aTwipsPerPixel(0)
> Next ctl
> StandardizeControlDimensionsExit:
> Echo -1
> DoCmd.Close acReport, ReportName, acSaveYes
> Exit Sub
> StandardizeControlDimensionsErr:
> With Err
> MsgBox .Description, vbCritical, "Error # " & .Number
> End With
> Resume StandardizeControlDimensionsExit
> End Sub
>
> Public Function TwipsPerPixel()
> Dim aTwipsPerPixel$(0 To 1)
> Dim DesktopWindow&
> Dim DesktopWindowDeviceHandle&
> DesktopWindowDeviceHandle = GetDC(DesktopWindow)
> aTwipsPerPixel(0) = TWIPSPERINCH \ GetDeviceCaps
> (DesktopWindowDeviceHandle, LOGPIXELSX)
> aTwipsPerPixel(1) = TWIPSPERINCH \ GetDeviceCaps
> (DesktopWindowDeviceHandle, LOGPIXELSY)
> ReleaseDC DesktopWindow, DesktopWindowDeviceHandle
> TwipsPerPixel = aTwipsPerPixel
> End Function
>
> One more time: for anyone thinking of trying this; do it on a throw away
> copy of the report, please..

Re: Export to RTF

Phil Stanton wrote:
> Interesting thought, Lyle.
>
> All 3 computers are working at different screen resolutions and after
> running your code needless to say the widths change. Then I run into
> all sorts of problems with overlapping controls. However I guess that
> your remarks apply to Access rather than Word (RTF File), and
> everything is perfect in the Access reports with the margins at 6 mm
> and control widths at 15.01. The problem only become apparent after exporting
> to Word.

Compare the width of spaces between words in Word and Access as well as the
space between characters (the latter is admittedly pretty difficult). They are
not the same and it throws off the calculations made during the export.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

Re: Export to RTF

As you say Rick, difficult to be sure, but at 500% zoom there appears no
difference between the fonts and spacings

Phil


"Rick Brandt" wrote in message
news:6Njbj.769$6%.630@nlpi061.nbdc.sbc.com...
> Phil Stanton wrote:
>> Interesting thought, Lyle.
>>
>> All 3 computers are working at different screen resolutions and after
>> running your code needless to say the widths change. Then I run into
>> all sorts of problems with overlapping controls. However I guess that
>> your remarks apply to Access rather than Word (RTF File), and
>> everything is perfect in the Access reports with the margins at 6 mm
>> and control widths at 15.01. The problem only become apparent after
>> exporting to Word.
>
> Compare the width of spaces between words in Word and Access as well as
> the space between characters (the latter is admittedly pretty difficult).
> They are not the same and it throws off the calculations made during the
> export.
>
> --
> Rick Brandt, Microsoft Access MVP
> Email (as appropriate) to...
> RBrandt at Hunter dot com
>