headers
Jörn Kottmann | 2 Jun 11:51
Picon

Failed to resolve font with embed-url 'file:///c:/WINDOWS/Fonts/pala.TTF'

Hi,

when I am building our docbook on linux or mac os. I get this exception:

     [java] SEVERE: Exception
     [java] org.apache.fop.apps.FOPException: Failed to resolve font 
with embed-url 'file:///c:/WINDOWS/Fonts/pala.TTF'
     [java]     at org.apache.fop.util.LogUtil.handleError(LogUtil.java:38)
     [java]     at 
org.apache.fop.render.PrintRendererConfigurator.getFontInfoFromConfiguration(PrintRendererConfigurator.java:275)
     [java]     at 
org.apache.fop.render.PrintRendererConfigurator.buildFontListFromConfiguration(PrintRendererConfigurator.java:207)
     [java]     at 
org.apache.fop.render.PrintRendererConfigurator.configure(PrintRendererConfigurator.java:95)
     [java]     at 
org.apache.fop.render.pdf.PDFRendererConfigurator.configure(PDFRendererConfigurator.java:71)
     [java]     at 
org.apache.fop.render.RendererFactory.createRenderer(RendererFactory.java:187)
     [java]     at 
org.apache.fop.area.RenderPagesModel.<init>(RenderPagesModel.java:68)
     [java]     at 
org.apache.fop.area.AreaTreeHandler.setupModel(AreaTreeHandler.java:127)
     [java]     at 
org.apache.fop.area.AreaTreeHandler.<init>(AreaTreeHandler.java:102)
     [java]     at 
org.apache.fop.render.RendererFactory.createFOEventHandler(RendererFactory.java:224)
     [java]     at 
org.apache.fop.fo.FOTreeBuilder.<init>(FOTreeBuilder.java:100)
     [java]     at 
org.apache.fop.apps.Fop.createDefaultHandler(Fop.java:100)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jörn Kottmann (JIRA | 2 Jun 12:41
Picon
Favicon

[jira] Closed: (UIMA-1360) Graduate the Cas Editor out of the sandbox


     [
https://issues.apache.org/jira/browse/UIMA-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jörn Kottmann closed UIMA-1360.
-------------------------------

    Resolution: Fixed

> Graduate the Cas Editor out of the sandbox
> ------------------------------------------
>
>                 Key: UIMA-1360
>                 URL: https://issues.apache.org/jira/browse/UIMA-1360
>             Project: UIMA
>          Issue Type: Task
>            Reporter: Jörn Kottmann
>            Assignee: Jörn Kottmann
>             Fix For: 2.3
>
>
> This task includes:
> - Moving the Cas Editor source code to uimaj
> - Merging the Cas Editor documentation into the main UIMA documentation
> - Updating JIRA
> - Integrate Cas Editor into UIMA build

--

-- 
This message is automatically generated by JIRA.
-
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jörn Kottmann (JIRA | 2 Jun 13:33
Picon
Favicon

[jira] Commented: (UIMA-1350) Cas Editor: Add printing support


    [
https://issues.apache.org/jira/browse/UIMA-1350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715486#action_12715486
] 

Jörn Kottmann commented on UIMA-1350:
-------------------------------------

Right now only the text is printed without any annotations.

> Cas Editor: Add printing support
> --------------------------------
>
>                 Key: UIMA-1350
>                 URL: https://issues.apache.org/jira/browse/UIMA-1350
>             Project: UIMA
>          Issue Type: Improvement
>          Components: CasEditor
>            Reporter: Jörn Kottmann
>            Assignee: Jörn Kottmann
>            Priority: Minor
>
> It should be possible to print out text together with annotations like in the open editor.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jörn Kottmann (JIRA | 2 Jun 14:10
Picon
Favicon

[jira] Closed: (UIMA-1362) Cas Editor pom should use ${uimaj-release-version variable instead of hardcoded version string


     [
https://issues.apache.org/jira/browse/UIMA-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jörn Kottmann closed UIMA-1362.
-------------------------------

    Resolution: Fixed

> Cas Editor pom should use ${uimaj-release-version variable instead of hardcoded version string
> ----------------------------------------------------------------------------------------------
>
>                 Key: UIMA-1362
>                 URL: https://issues.apache.org/jira/browse/UIMA-1362
>             Project: UIMA
>          Issue Type: Improvement
>          Components: CasEditor
>            Reporter: Jörn Kottmann
>            Assignee: Jörn Kottmann
>            Priority: Trivial
>             Fix For: 2.3
>
>

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jörn Kottmann (JIRA | 2 Jun 14:10
Picon
Favicon

[jira] Created: (UIMA-1362) Cas Editor pom should use ${uimaj-release-version variable instead of hardcoded version string

Cas Editor pom should use ${uimaj-release-version variable instead of hardcoded version string
----------------------------------------------------------------------------------------------

                 Key: UIMA-1362
                 URL: https://issues.apache.org/jira/browse/UIMA-1362
             Project: UIMA
          Issue Type: Improvement
          Components: CasEditor
            Reporter: Jörn Kottmann
            Assignee: Jörn Kottmann
            Priority: Trivial
             Fix For: 2.3

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 1 comment |
headers
Branimir Lambov (JIRA | 2 Jun 15:02
Picon
Favicon

[jira] Created: (UIMA-1363) Access to individual type index iterators

Access to individual type index iterators
-----------------------------------------

                 Key: UIMA-1363
                 URL: https://issues.apache.org/jira/browse/UIMA-1363
             Project: UIMA
          Issue Type: Improvement
          Components: Core Java Framework
         Environment: Windows XP, LanguageWare
            Reporter: Branimir Lambov

UIMA feature structure iterators for a given type always include its subtypes. While this is generally the
best thing to do, if an application requires more precise control over the types it needs an ability to
iterate over the instances of a specific type only, leaving the subtypes out. In the current UIMA this is
not possible to achieve.

This is especially important for performance as iterating over an aggregate index is vastly more
complicated than listing an individual index. In certain real-world scenarios using our AFST engine we
are able to achieve close to 20% performance improvement on complete processing pipelines by simply
giving the AFST type set iterator access to individual type iterators.

The attached patch implements a new "ll_leafIterator()" method in LowLevelIndex which returns an
iterator over the root type of an index. It also includes a simple alternative to
FSIndexRepositoryImpl.PointerIterator for leaf types, also improving the performance when
iterating over leaf types.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Branimir Lambov (JIRA | 2 Jun 15:04
Picon
Favicon

[jira] Updated: (UIMA-1363) Access to individual type index iterators


     [
https://issues.apache.org/jira/browse/UIMA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Branimir Lambov updated UIMA-1363:
----------------------------------

    Attachment: LeafIteratorPatch.txt

ll_leafIterator() implementation.

> Access to individual type index iterators
> -----------------------------------------
>
>                 Key: UIMA-1363
>                 URL: https://issues.apache.org/jira/browse/UIMA-1363
>             Project: UIMA
>          Issue Type: Improvement
>          Components: Core Java Framework
>         Environment: Windows XP, LanguageWare
>            Reporter: Branimir Lambov
>         Attachments: LeafIteratorPatch.txt
>
>
> UIMA feature structure iterators for a given type always include its subtypes. While this is generally
the best thing to do, if an application requires more precise control over the types it needs an ability to
iterate over the instances of a specific type only, leaving the subtypes out. In the current UIMA this is
not possible to achieve.
> This is especially important for performance as iterating over an aggregate index is vastly more
complicated than listing an individual index. In certain real-world scenarios using our AFST engine we
(Continue reading)

Permalink | Reply | 0 comments |
headers
Branimir Lambov (JIRA | 2 Jun 15:41
Picon
Favicon

[jira] Created: (UIMA-1364) Concurrent modification checks dominate index iteration time.

Concurrent modification checks dominate index iteration time.
-------------------------------------------------------------

                 Key: UIMA-1364
                 URL: https://issues.apache.org/jira/browse/UIMA-1364
             Project: UIMA
          Issue Type: Improvement
            Reporter: Branimir Lambov
         Attachments: ConcurrentModificationPatch.txt

Iterating over the annotation index with even a moderate number of defined types is dominated by the time
spent checking individual indexes for concurrent modification. This is due to the fact that concurrent
modification checks are done on all types being iterated over, even if the iteration only needs to process
a couple of iterators. In fact, checking all iterators for modification has linear complexity in the
number of subiterators used, while the actual iteration can be implemented with logarithmic complexity
using e.g. a binary heap.

The UIMA documentation and JavaDoc do not state that the iterators should always recognize concurrent
modification (FSIterator JavaDoc states "Implementations of this interface are not required to be
fail-fast. That is, if the iterator's collection is modified, the effects on the iterator are in general
undefined."). It thus makes sense to reduce the number of iterators being tested for concurrent
modification at each moveToNext() step.

The attached patch replaces the checkConcurrentModificationAll() call in
FSIndexRepositoryImpl.PointerIterator.moveToNext() with concurrent modification checks on only
the iterators being used by the step; as the iterator becomes invalid it also checks all involved
iterators for modification. By doing this it should be able to catch almost all concurrent modification
without the excessive overhead.

In one of our performance tests iterating over the annotation index with 140 types defined is more than
(Continue reading)

Permalink | Reply | 3 comments |
headers
Branimir Lambov (JIRA | 2 Jun 15:41
Picon
Favicon

[jira] Updated: (UIMA-1364) Concurrent modification checks dominate index iteration time.


     [
https://issues.apache.org/jira/browse/UIMA-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Branimir Lambov updated UIMA-1364:
----------------------------------

    Attachment: ConcurrentModificationPatch.txt

> Concurrent modification checks dominate index iteration time.
> -------------------------------------------------------------
>
>                 Key: UIMA-1364
>                 URL: https://issues.apache.org/jira/browse/UIMA-1364
>             Project: UIMA
>          Issue Type: Improvement
>            Reporter: Branimir Lambov
>         Attachments: ConcurrentModificationPatch.txt
>
>
> Iterating over the annotation index with even a moderate number of defined types is dominated by the time
spent checking individual indexes for concurrent modification. This is due to the fact that concurrent
modification checks are done on all types being iterated over, even if the iteration only needs to process
a couple of iterators. In fact, checking all iterators for modification has linear complexity in the
number of subiterators used, while the actual iteration can be implemented with logarithmic complexity
using e.g. a binary heap.
> The UIMA documentation and JavaDoc do not state that the iterators should always recognize concurrent
modification (FSIterator JavaDoc states "Implementations of this interface are not required to be
fail-fast. That is, if the iterator's collection is modified, the effects on the iterator are in general
undefined."). It thus makes sense to reduce the number of iterators being tested for concurrent
(Continue reading)

Permalink | Reply | 0 comments |
headers
Branimir Lambov (JIRA | 2 Jun 15:45
Picon
Favicon

[jira] Created: (UIMA-1365) Code trying to ensure reverse iterators list items in the opposite order of forward ones is present but not working

Code trying to ensure reverse iterators list items in the opposite order of forward ones is present but not working
-------------------------------------------------------------------------------------------------------------------

                 Key: UIMA-1365
                 URL: https://issues.apache.org/jira/browse/UIMA-1365
             Project: UIMA
          Issue Type: Bug
          Components: Core Java Framework
            Reporter: Branimir Lambov
            Priority: Minor

FSIndexRepositoryImpl contains pieces of code that are meant to ensure forward and reverse iterators are
inverses of each other by doing additional comparison by FS address to resolve equality. However, this is
not fully implemented and isn't working properly.

The iteratorComparator defined by the PointerIterator class is not used for sorting elements in
moveToNext() and moveToPrevious(), where the default comparators for the iterators are used instead.
For the typical use of PointerIterator of listing the annotation index this does not cause a problem as the
type priorities ensure ordering between indexes of different types, while the ordering is always
defined within the individual indexes.

The piece of code implementing the extra comparison should either be removed or corrected.

--

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Permalink | Reply | 2 comments |

Gmane