On Tue, 24 Aug 2010, Graeme Geldenhuys wrote:
On 24 August 2010 16:48, Marco van de Voort wrote:
routines, and dwlinear were never updated properly. Do similar links look ok
in the latex output? It makes more sense to compare ipf output with that?
I can now confirm that *all* Linear output
On 24 August 2010 16:48, Marco van de Voort wrote:
> routines, and dwlinear were never updated properly. Do similar links look ok
> in the latex output? It makes more sense to compare ipf output with that?
I can now confirm that *all* Linear output writers have this bug.
Below is the same help te
In our previous episode, Graeme Geldenhuys said:
> > I don't understand? You don't have to have Latex to inspect latex output of
> > fpdoc ?
>
> I can output latex for fpGUI class docs, but I don't know how to
> generate latex output for RTL & FCL. Using the make command, it always
> wants to buil
On Tue, 24 Aug 2010, Graeme Geldenhuys wrote:
On 24 August 2010 20:06, Marco van de Voort wrote:
I don't understand? You don't have to have Latex to inspect latex output of
fpdoc ?
I can output latex for fpGUI class docs, but I don't know how to
generate latex output for RTL & FCL. Using t
On 24 August 2010 20:06, Marco van de Voort wrote:
>
> I don't understand? You don't have to have Latex to inspect latex output of
> fpdoc ?
I can output latex for fpGUI class docs, but I don't know how to
generate latex output for RTL & FCL. Using the make command, it always
wants to build the wh
In our previous episode, Graeme Geldenhuys said:
> > in the latex output? It makes more sense to compare ipf output with that?
>
> I can't generate Latex output, but I can generate RTF output,
I don't understand? You don't have to have Latex to inspect latex output of
fpdoc ?
__
On 24 August 2010 17:37, Michael Van Canneyt wrote:
>
> GetLabel has the TPasElement - it's all it can rely on, because there may
> not be a description
> element.
>
> DescrBeginLink on the other hand starts from a tag's "id" attribute
> and starts looking for the target XML element tag. NOT for t
On Tue, 24 Aug 2010, Graeme Geldenhuys wrote:
Op 2010-08-24 16:51, Michael Van Canneyt het geskryf:
:link reftype=hd refid=fcl.CreatePipeStreams:elink.,
Just to explain IPF links more. The link part is in the refid value string
and terminates at the first period (dot). When I receive a link
Op 2010-08-24 16:48, Marco van de Voort het geskryf:
> routines, and dwlinear were never updated properly. Do similar links look ok
> in the latex output? It makes more sense to compare ipf output with that?
I can't generate Latex output, but I can generate RTF output, which is also
a linear write
Op 2010-08-24 16:51, Michael Van Canneyt het geskryf:
>> :link reftype=hd refid=fcl.CreatePipeStreams:elink.,
Just to explain IPF links more. The link part is in the refid value string
and terminates at the first period (dot). When I receive a link with
periods in them, I replace them with undersc
On Tue, 24 Aug 2010, Graeme Geldenhuys wrote:
Op 2010-08-24 13:16, Marco van de Voort het geskryf:
Did you read my msg from a few days back? Unit order matters.
Yes, I know about that from years ago, and that still doesn't solve the
problem, even in FCL or fpGUI docs. And even if a link po
In our previous episode, Graeme Geldenhuys said:
> > Did you read my msg from a few days back? Unit order matters.
>
> Yes, I know about that from years ago, and that still doesn't solve the
> problem, even in FCL or fpGUI docs. And even if a link points to an element
> in the same unit.
>
> Here
Op 2010-08-24 13:16, Marco van de Voort het geskryf:
>
> Did you read my msg from a few days back? Unit order matters.
Yes, I know about that from years ago, and that still doesn't solve the
problem, even in FCL or fpGUI docs. And even if a link points to an element
in the same unit.
Here is wha
In our previous episode, Graeme Geldenhuys said:
> PS:
> Resolving links are still very broken in fpdoc. RTF and IPF output (just
> two output formats that support links) using FPC's RTL & FCL docs or tiOPF
> & fpGUI class docs show numerous unresolved/broken links. I tried to debug
> the ResolveLi
Michael Schnell schrieb:
On 08/20/2010 12:39 PM, Hans-Peter Diettrich wrote:
The many conditional parts, which are not even properly chained by
{$ELSEIF ...}, make the maintance and refactoring a mess :-(
While moving to OO paradigms could make the code slightly slower, I
suppose that support
Hans-Peter Diettrich wrote:
Can we make string literals accepted with embedded whitespace between
ordinal characters?
Currently this is not accepted:
const x: string = #1 #2 #3;
and must be written as
const x: string = #1#2#3; //not very readable
you can use
const x: string = #1 + #2 + #3;
On Tue, 24 Aug 2010, Felipe Monteiro de Carvalho wrote:
On Tue, Aug 24, 2010 at 11:59 AM, Michael Van Canneyt
wrote:
Why, did you start on one already ?
No, just curiosity and I though about mentioning that if you start
one, it would be probably good to make it a generic document
manipulat
On Tue, Aug 24, 2010 at 11:59 AM, Michael Van Canneyt
wrote:
> Why, did you start on one already ?
No, just curiosity and I though about mentioning that if you start
one, it would be probably good to make it a generic document
manipulation framework, just like we already have:
fcl-image for rast
Op 2010-08-24 11:20, Michael Van Canneyt het geskryf:
>
> Nono, formatting was the least of our worries. We were glad to get it
> working at all. Patches with improvements are most welcome.
OK, that's good to know that OpenOffice isn't to blame. I tried OpenOffice
3.2 (at work) today, and formatt
On Tue, 24 Aug 2010, Felipe Monteiro de Carvalho wrote:
On Tue, Aug 24, 2010 at 11:20 AM, Michael Van Canneyt
wrote:
The plan is to create PDF directly, as soon as I have a suitable PDF
rendering engine which can be included in FPC.
Are you writing a PDF generator?
I'm just investigating
On Tue, Aug 24, 2010 at 11:20 AM, Michael Van Canneyt
wrote:
> The plan is to create PDF directly, as soon as I have a suitable PDF
> rendering engine which can be included in FPC.
Are you writing a PDF generator?
--
Felipe Monteiro de Carvalho
___
fp
Op 2010-08-24 11:16, Marco van de Voort het geskryf:
>
> How big was openoffice + java VM again?
OpenOffice is include with most linux distros and FreeBSD (no extra
download required), and "export to PDF" feature doesn't require Java runtime.
Either way, a lot less download and installation eff
On Tue, 24 Aug 2010, Hans-Peter Diettrich wrote:
Can we make string literals accepted with embedded whitespace between ordinal
characters?
No.
Michael.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/l
Can we make string literals accepted with embedded whitespace between
ordinal characters?
Currently this is not accepted:
const x: string = #1 #2 #3;
and must be written as
const x: string = #1#2#3; //not very readable
DoDi
___
fpc-devel maillist
On Tue, 24 Aug 2010, Graeme Geldenhuys wrote:
Hi
Has anybody been using the RTF output writer of fpdoc? I had a closer look
at it last night, and the output (formatting) looks pretty horrible when
viewed using OpenOffice 2.4.
This is a known problem :-)
Now I know you get tons of versio
In our previous episode, Graeme Geldenhuys said:
> The reason I ask. I think generating RTF docs, opening it with OpenOffice,
> and then exporting it to PDF is a lot more accessible to users that
> downloading and installing the 250MB support files for Latex to work. Just
> a thought.
How big was
Hi
Has anybody been using the RTF output writer of fpdoc? I had a closer look
at it last night, and the output (formatting) looks pretty horrible when
viewed using OpenOffice 2.4.
Now I know you get tons of version of RTF and it also depends on what RTF
viewer you are using (WordPad, OpenOffice,
On Tue, August 24, 2010 08:26, Graeme Geldenhuys wrote:
> Op 2010-08-24 00:09, Tomas Hajny het geskryf:
>>
>> Also note that FP bombs out under OS/2 when adding all the CHM files
>> and trying to open contents (I guess that this would be probably some
>> OS/2 specific bug in RTL, but I haven't had
28 matches
Mail list logo
