text:
require 'neo4j/core/cypher_session/adaptors'
require 'neo4j/core/cypher_session/responses/embedded'

module Neo4j
  module Core
    class CypherSession
      module Adaptors
        class Embedded < Base
          def initialize(path, options = {})
            fail 'JRuby is required for embedded mode' if RUBY_PLATFORM != 'java'
            fail ArgumentError, "Invalid path: #{path}" if !File.directory?(path)

            @path = path
            @options = options
          end

          def connect
            factory    = Java::OrgNeo4jGraphdbFactory::GraphDatabaseFactory.new
            db_service = factory.newEmbeddedDatabaseBuilder(@path)
            db_service.loadPropertiesFromFile(@options[:properties_file]) if @options[:properties_file]
            db_service.setConfig(@options[:properties_map])               if @options[:properties_map]

            @graph_db = db_service.newGraphDatabase
          end

          def query_set(queries)
            # I think that this is the best way to do a batch in embedded...
            # Should probably do within a transaction in case of errors...

            transaction do
              self.class.instrument_transaction do
                self.class.instrument_queries(queries)

                execution_results = queries.map do |query|
                  engine.execute(query.cypher, indifferent_params(query))
                end

                Responses::Embedded.new(execution_results).results
              end
            end
          end

          def start_transaction
            @transaction = @graph_db.begin_tx
          end

          def end_transaction
            if @transaction.nil?
              fail 'Cannot close transaction without starting one'
            end

            @transaction.success
            @transaction.close
          end

          def transaction_started?
            !!@transaction
          end

          def version
            if defined?(::Neo4j::Community)
              ::Neo4j::Community::NEO_VERSION
            elsif defined?(::Neo4j::Enterprise)
              ::Neo4j::Enterprise::NEO_VERSION
            else
              fail 'Could not determine embedded version!'
            end
          end

          instrument(:transaction, 'neo4j.core.embedded.transaction', []) do |_, start, finish, _id, _payload|
            ms = (finish - start) * 1000

            " #{ANSI::BLUE}EMBEDDED CYPHER TRANSACTION:#{ANSI::CLEAR} #{ANSI::YELLOW}#{ms.round}ms#{ANSI::CLEAR}"
          end

          private

          def indifferent_params(query)
            params = query.parameters
            params.each { |k, v| params[k] = HashWithIndifferentAccess.new(params[k]) if v.is_a?(Hash) && !v.respond_to?(:nested_under_indifferent_access) }
            HashWithIndifferentAccess.new(params)
          end

          def engine
            @engine ||= Java::OrgNeo4jCypherJavacompat::ExecutionEngine.new(@graph_db)
          end
        end
      end
    end
  end
end


text:
package com.breadwallet.crypto;

public enum TransferDirection {
    SENT,
    RECEIVED,
    RECOVERED;

    @Override
    public String toString() {
        switch (this) {
            case RECOVERED:
                return "Recovered";
            case SENT:
                return "Sent";
            case RECEIVED:
                return "Received";
            default:
                return super.toString();
        }
    }
}

redpajama_set_name: RedPajamaGithub


text:
package org.gradle.test.performance.mediummonolithicjavaproject.p214;

import org.junit.Test;
import static org.junit.Assert.*;

public class Test4294 {
    Production4294 objectUnderTest = new Production4294();

    @Test
    public void testProperty0() {
        String value = "value";
        objectUnderTest.setProperty0(value);
        assertEquals(value, objectUnderTest.getProperty0());
    }

    @Test
    public void testProperty1() {
        String value = "value";
        objectUnderTest.setProperty1(value);
        assertEquals(value, objectUnderTest.getProperty1());
    }

    @Test
    public void testProperty2() {
        String value = "value";
        objectUnderTest.setProperty2(value);
        assertEquals(value, objectUnderTest.getProperty2());
    }

    @Test
    public void testProperty3() {
        String value = "value";
        objectUnderTest.setProperty3(value);
        assertEquals(value, objectUnderTest.getProperty3());
    }

    @Test
    public void testProperty4() {
        String value = "value";
        objectUnderTest.setProperty4(value);
        assertEquals(value, objectUnderTest.getProperty4());
    }

    @Test
    public void testProperty5() {
        String value = "value";
        objectUnderTest.setProperty5(value);
        assertEquals(value, objectUnderTest.getProperty5());
    }

    @Test
    public void testProperty6() {
        String value = "value";
        objectUnderTest.setProperty6(value);
        assertEquals(value, objectUnderTest.getProperty6());
    }

    @Test
    public void testProperty7() {
        String value = "value";
        objectUnderTest.setProperty7(value);
        assertEquals(value, objectUnderTest.getProperty7());
    }

    @Test
    public void testProperty8() {
        String value = "value";
        objectUnderTest.setProperty8(value);
        assertEquals(value, objectUnderTest.getProperty8());
    }

    @Test
    public void testProperty9() {
        String value = "value";
        objectUnderTest.setProperty9(value);
        assertEquals(value, objectUnderTest.getProperty9());
    }

}


text:
    <form class="form-horizontal" role="form">

Information about driver {{stats.name}}

                 Edit
                 Oauth2 authentication

                     Start
                     Stop
                     Restart

            Name

                {{stats.name}}

            Time

                {{stats.time | date:'EEEE, MMMM d, y h:mm a'}}

            Status

                {{stats.status}}

            {{key}}

                <input type="text" class="form-control" id="statsOption-{{key}}" placeholder="{{value}}" readonly>

    </form>


text:
JSdep (DOM-DEPENDENCY ANALYSIS)
=========================
* Citing JSdep
```
@inproceedings{DBLP:conf/sigsoft/SungKS016,
  author    = {Chungha Sung and
               Markus Kusano and
               Nishant Sinha and
               Chao Wang},
  title     = {Static {DOM} event dependency analysis for testing web applications},
  booktitle = {Proceedings of the 24th {ACM} {SIGSOFT} International Symposium on
               Foundations of Software Engineering, {FSE} 2016, Seattle, WA, USA,
               November 13-18, 2016},
  pages     = {447--459},
  year      = {2016},
  crossref  = {DBLP:conf/sigsoft/2016},
  url       = {https://doi.org/10.1145/2950290.2950292},
  doi       = {10.1145/2950290.2950292},
  timestamp = {Tue, 06 Nov 2018 16:59:23 +0100},
  biburl    = {https://dblp.org/rec/bib/conf/sigsoft/SungKS016},
  bibsource = {dblp computer science bibliography, https://dblp.org}
}
```

* JSdep is a tool to find DOM-event dependency of a web application including traditional control and data-dependency using datalog constraints.

* It traverses one JavaScript file statically and finds the relationship between two events of DOMs.

* This tool includes a modified version of Artemis to show the evaluation as presented in the FSE paper (to appear).

* The characteristics of this tool
    - Static & interprocedural & context-insensitive alias anlaysis
    - This tool does not support DOM-alias anlaysis
    - This tool does not support extraction of Javascript from HTML (All JavaScripts extracted manually for the benchmarks we have)

* Structure of JSdep
    - <img src="https://cloud.githubusercontent.com/assets/8551376/16468537/5d6c5dd4-3e1a-11e6-8e29-0e60dc3480cf.png" width="600">
    - In this figure, all directories of the repository we have are represented with a folder, and output files are represented with a notepad icon. And, commands next to arrows are actual scripts you can use in JSdep. Mainly, there are three parts in JSdep:
    - DOM Analysis - This part contains our main analysis. It consists of 3 directories (src, z3_rules, node_modules). After installing all dependencies, when you run scripts named make build-dep with a file name or make build-dep-all, the analysis will produce 3 files (dep.txt, numConstraints.txt, z3.time) under info directory of each benchmark. Dependency result is printed in dep.txt, and analysis time of each file is recorded in z3.time. Also, the number of constraints generated is recorded in numConstraints.txt.
    - Modified Artemis - To make users check the usefulness of our analysis, we provide a Artemis modified to use the information we have. Before running Artemis you have to install it. After you install the modified version of Artemis, you can compare two versions of it. By running command make run-artemis with a file name or make run-artemis-all, it uses dep.txt under each benchmark and produces two files under artemis-result directory for each benchmark. old_artemis.stdout is the output of previous version of Artemis, and new-artemis.stdout is output of a modified version of Artemis which uses the information in dep.txt.
    - Raw-data - This directory is provided for users who want to make tables without any installation and running our analysis. All data have been uploaded and the structure of this directory is same as the one of benchmark. If you run commands make table1, make table2 and make table3, you can get each table used in the paper. The table will be printed on terminal and form is for latex. Therefore, if you copy the print and paste it to latex, it will show the same table as we showed in the paper. And, for those who wants to make table with new data generated, we provide one more command, make fetch-data. This command will fetch all data under benchmark to raw-data directory. Same as before, after fetching new data, you can easily make same structure tables by running make table commands.

Contributors
=========================
The following people have contributed to the this appliacation and the paper:

* Chungha Sung (sch8906/at/vt/edu)
* Markus Kusano (mukusano/at/vt/edu)
* Nishant Sinha
* Chao Wang (chaowang/at/vt/edu)

PROGRAM DEPENDENCIES
=========================
0. Environment

    * We only tested this program on Ubuntu 12.04
    * We haven't checked it with other Ubuntu versions

1. To run only static analysis to run DOM-dependency relationships,
    it needs these dependencies:

    * Z3 (https://github.com/Z3Prover/z3), any version (tested with 4.4.1).
    * nodejs (To install this, type ``sudo apt-get install nodejs``)
    * realpath (To install this, type ``sudo apt-get install realpath``)

2. To test with Artemis, you have to install a modified version of Artemis first.

    * You can follow the instruction under artemis-modified directory to install it (it sometimes hard to install correctly, however due to the size limitation we cannot provide fully compiled version).
    * You have to use the version we provide because this version is modified to compare the previous version of Artemis and the modified version of Artemis which uses dependency relationships of our program.

3. The link for VM (ova file of Virtual Box) with JSdep installed (https://drive.google.com/open?id=1O70KDlfWHaN4J06Y5nhTqopBqiqCiYrq). However, this has been updated very long time ago, so maybe it has some issues.

USAGE
=========================
* make build-dep file=[filename]
    - build dependency relationships for a specified file
    - it will make these files under info directory under each benchmark directory
        * dep.txt: dependency relationships of a specified file
        * z3.time: analysis time
        * numConstraints.txt: number of constraints generated

* make build-dep-all
    - build dependency relationships for all files
    - it will make these files under info directory under each benchmark directory
        * dep.txt: dependency relationships of a specified file
        * z3.time: analysis time
        * numConstraints.txt: number of constraints generated

* make fetch-data
    - fetch all data needed to make result tables from benchmark directory to raw-data directory

* make table1
    - build a table1 used in the FSE paper using raw-data

* make table2
    - build a table2 used in the FSE paper using raw-data

* make table3
    - build a table3 used in the FSE paper using raw-data
    - you can change the iteration number in Makefile to build a table with a different number of iterations

===== You have to install the modifed version of Artemis we provide to run these comands below =====
* make run-artemis file=[filename] iter=[iteration]
    - you have to run dependency analysis to get dep.txt first
    - run previous version of Artemis with a specified file and a specified iteration number
* make run-artemis-all iter=[iteration]
    - you have to run dependency analysis to get dep.txt first
    - run previous version of Artemis with all files with a specified interation number

HOW TO INTERPRET dep.txt?
=========================

If you run the program, you can see the file named dep.txt file under info directory.

There are lines of text, and each depedency relationships consist of 4 lines of text.

First and Second line indicate the name of DOM, and third and fourth line indicate the type of event.

For example, if the file content is
    1    dom1
    2    click
    3    dom2
    4    mousemove

dom1 and dom2 are name of DOM nodes and click and mousemove are the type of events for each DOM.

The meaning of these four lines is mousemove of test2 depends on click of test1.

Each four lines are related (e.g. 1~4, 5~8 ...)


text:
<?php
$I = new AcceptanceTester($scenario);
$I->wantTo('ensure that frontpage works');
$I->amOnPage('/');
$I->dontSee('whoops');


text:
SET @OLD_SQL_NOTES=@@SQL_NOTES, SQL_NOTES=0;

DELIMITER $$

DROP PROCEDURE IF EXISTS core_run_sql_v2 $$

-- DO NOT change this without reading the header!
CREATE PROCEDURE core_run_sql_v2 (
    p_sql_stmt varchar(1000)
)
BEGIN

    SET @sqlstmt = p_sql_stmt;

    SELECT CONCAT('Running sql: ', @sqlstmt);

    PREPARE stmt FROM @sqlstmt;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;
END $$

DROP PROCEDURE IF EXISTS core_add_column_v2$$

-- DO NOT change this without reading the header!
CREATE PROCEDURE core_add_column_v2 (
    p_table_name varchar(64),
    p_column_name varchar(64),
    p_column_type_info varchar(64) -- e.g. 'varchar(255) default NULL'
)
BEGIN
    DECLARE object_count integer;

    SELECT COUNT(1)
    INTO object_count
    FROM information_schema.columns
    WHERE table_schema = database()
    AND table_name = p_table_name
    AND column_name = p_column_name;

    IF object_count = 0 THEN
        CALL core_run_sql_v2(CONCAT(
            'alter table ', database(), '.', p_table_name,
            ' add column ', p_column_name, ' ', p_column_type_info));
    ELSE
        SELECT CONCAT(
            'Column ',
            p_column_name,
            ' already exists on table ',
            database(),
            '.',
            p_table_name);
    END IF;
END $$

DELIMITER ;

-- idempotent
CALL core_add_column_v2(
    'processor_filter',
    'min_meta_create_time_ms',
    'bigint DEFAULT NULL');
CALL core_add_column_v2(
    'processor_filter',
    'max_meta_create_time_ms',
    'bigint DEFAULT NULL');

UPDATE processor_filter SET max_meta_create_time_ms = create_time_ms WHERE reprocess = true;

DROP PROCEDURE IF EXISTS core_add_column_v2 ;
DROP PROCEDURE IF EXISTS core_run_sql_v2 ;

SET SQL_NOTES=@OLD_SQL_NOTES;

-- vim: set shiftwidth=4 tabstop=4 expandtab:


text:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.InteropServices;
using System.Text;
using System.Threading.Tasks;

namespace Azure.IoT.Internal.Tools
{
    internal class Win32Api
    {
        public const int INVALID_HANDLE_VALUE = -1;

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        public static extern IntPtr CreateFile(
             [MarshalAs(UnmanagedType.LPTStr)] string filename,
             [MarshalAs(UnmanagedType.U4)] FileAccess access,
             [MarshalAs(UnmanagedType.U4)] FileShare share,
             IntPtr securityAttributes, // optional SECURITY_ATTRIBUTES struct or IntPtr.Zero
             [MarshalAs(UnmanagedType.U4)] FileMode creationDisposition,
             [MarshalAs(UnmanagedType.U4)] FileAttributes flagsAndAttributes,
             IntPtr templateFile);

        [DllImport("kernel32.dll", SetLastError = true)]
        [return: MarshalAs(UnmanagedType.Bool)]
        public static extern bool CloseHandle(IntPtr hObject);

        [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
        public static extern bool GetCommState(IntPtr hFile, ref SerialPortState lpDcb);

        [DllImport("kernel32.dll")]
        public static extern bool SetCommState(IntPtr hFile, [In] ref SerialPortState lpDCB);

        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool GetCommTimeouts(IntPtr hFile, [In] ref SerialPortTimeouts lpCommTimeouts);

        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool SetCommTimeouts(IntPtr hFile, [In] ref SerialPortTimeouts lpCommTimeouts);

        [DllImport("kernel32.dll", SetLastError = true)]
        [return: MarshalAsAttribute(UnmanagedType.Bool)]
        public static extern bool SetCommBreak(IntPtr fileHandle);

        [DllImport("kernel32.dll")]
        public static extern bool ClearCommBreak(IntPtr fileHandle);

        [DllImport("kernel32.dll", SetLastError = true)]
        public static extern bool ReadFile(IntPtr hFile, [Out] byte[] lpBuffer,
           uint nNumberOfBytesToRead, out uint lpNumberOfBytesRead, IntPtr lpOverlapped);

        [DllImport("kernel32.dll")]
        public static extern bool WriteFile(IntPtr hFile, byte[] lpBuffer,
           uint nNumberOfBytesToWrite, out uint lpNumberOfBytesWritten,
           IntPtr lpOverlapped);

        public static int GetLastError()
        {
            return Marshal.GetLastWin32Error();
        }

        public static IntPtr CreateFile(string portName)
        {
            return CreateFile(@"\\.\" + portName, FileAccess.GenericWrite | FileAccess.GenericRead, FileShare.None, IntPtr.Zero, FileMode.OpenExisting, FileAttributes.Normal, IntPtr.Zero);
        }
    }
}


text:
import React, { Component } from 'react';
import { Alert, Button, Panel } from 'react-bootstrap';
import Toolbar from './Toolbar';
import Liberator from './Liberator';
import SourceLink from './SourceLink';
import ReactWrappyText from 'react-wrappy-text';

require('./../styles/demo6.css');

export default class Demo6 extends Component {

    constructor(props) {
        super(props);

        this.state = {
            active: false,
            visible: true
        };

        this.onButtonClick = this.onButtonClick.bind(this);
        this.changeVisibility = this.changeVisibility.bind(this);
    }

    onButtonClick() {
        this.setState({
            active: !this.state.active
        });
    }

    changeVisibility() {
        this.setState({
            visible: !this.state.visible
        });
    }

    render() {
        var active = this.state.active,
            visible = this.state.visible,
            className = 'popup ' + (active ? 'green' : 'red'),
            buttonIcon = active ?
                 :
                ,
            buttonText = active ? 'Active: true' : 'Active: false',
            buttonIcon2 = visible ?
                 :
                ,
            buttonText2 = visible ? 'Visible: true' : 'Visible: false',
            classNameLeft = className + ' left',
            classNameRight = className + ' right';

        return (

                <Alert bsStyle="success">

<ReactWrappyText>Demo 6 - Multiple children</ReactWrappyText>

                    Click the buttons to liberate both children.

                    Two children are wrapped into single Liberator.

                    Both are displayed in the same overlay.

                    <SourceLink>Demo6.js</SourceLink>

                </Alert>
                <Button bsStyle="primary" bsSize="large" onClick={this.onButtonClick}>{buttonIcon} {buttonText}</Button>
                <Button bsSize="large" className="indent-left" onClick={this.changeVisibility}>{buttonIcon2} {buttonText2}</Button>

                <Liberator active={active} visible={visible}>

{active ? 'In popup' : 'Normal'}

{active ? 'In popup' : 'Normal'}

                </Liberator>

        );
    }
}


text:
<!DOCTYPE html>

    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <meta name="description" content="">
    <meta name="author" content="">

    <title>2015 Global Cre8 Summit</title>

    <link href="css/bootstrap.min.css" rel="stylesheet">

    <link href="css/summit-model.css" rel="stylesheet">

    <link href="http://fonts.googleapis.com/css?family=Open+Sans:300italic,400italic,600italic,700italic,800italic,400,300,600,700,800" rel="stylesheet" type="text/css">
    <link href="http://fonts.googleapis.com/css?family=Josefin+Slab:100,300,400,600,700,100italic,300italic,400italic,600italic,700italic" rel="stylesheet" type="text/css">

Global Cre8 Summit

May 23 - 26, 2015 | Shenzhen, P.R.China

                <button type="button" class="navbar-toggle" data-toggle="collapse" data-target="#bs-example-navbar-collapse-1">
                    Toggle navigation

                </button>

                2015 Global Cre8 Summit

                        Home

                        About

                        Speakers

                        Register

                        Schedule

                        Contact

About
                        Global Cre8 Summit

The Global Cre8 Summit is a 4-day event for makers and entrepreneurs to inspire the next generation, demo new products, exchange ideas, meet industry leaders and build connections with Shenzhen business and manufacturing centers. Global Cre8 Summit will take place at the Tianan Cyber Park in Shenzhen, China from May 23 - May 26, 2015.

Globalization continues to change the nature of manufacturing and entrepreneurship. China in particular has been a powerful force in hardware production, and its massive consumer base will play an increasingly important role in consumer electronics. As China's economic system and venture capital environment continue to mature, makers and entrepreneurs from all over the world will find having a foothold in China increasingly valuable.

This event is an experiment in bringing together people of diverse backgrounds to the hardware manufacturing center of the world: Shenzhen, China. Shenzhen is one of China's most successful Special Economic Zones (SEZ), having transformed from a small village to an industrial powerhouse in a span of 30 years. Shenzhen is home to the headquarters of a variety of leading technology companies and is best known internationally for its extraordinary electronic manufacturing capability, leading to the moniker "the Silicon Valley of hardware." This unique environment is perfectly suited for a meeting of the world's future creators and innovators.

The first two days will feature keynote speakers, project exhibitions, and networking events (one of them featuring a mystery contest!). The last two days will offer tours of some of Shenzhen's manufacturing centers and technology headquarters, giving participants an exclusive look at how the modern world is made.

The landscape for creating everything from projects to companies is changing rapidly. We hope to see you there at the forefront in Shenzhen!

                        Why  Attend

Inspire the next generation: Global Cre8 Summit features public events that will allow makers to share their stories with the next generation. We hope to inspire the young people of Shenzhen to grow into the hackers, makers, and creators of the future.

Share ideas, see what's possible: Mingle with other hackers, makers and entrepreneurs working at the edge technology. Discover how Shenzhen makes hardware feel like software. See what's possible in the Silicon Valley of hardware.

Connect with manufacturers: Building relationships with trusted manufacturing partners in Shenzhen is notoriously difficult for small startups based in the United States. Stories of companies spending tens or even hundreds of thousands of dollars to middlemen for "connections" abound. At Cre8 Summit you'll have a chance to meet trusted manufacturing partners and see the factories for yourself.

Understand the Chinese consumer market: Massive opportunity and massive competition are common descriptors for the Chinese consumer market. From apps to appliances, successfully selling in China requires understanding market, media, and culture. Learn what it takes for success on the ground in one of China's most important industrial cities.

                        Companies We'll Visit

DJI

                          drones

                        BGI

                          genomics

                        BYD

                          the new age of electric vehicles

Foxconn

                          manufacturing

                        Seeed Studio

                          fusion PCB service

Huaqiangbei

                         Electronics Market

Royole

                          next-generation displays

Kuang-Chi

                          photonic technology

Jiawei

                          solar energy

Our
                        Team

US Team

                        (Left to right: Yulin Zheng, Yipu Zheng, Daniel Dandurand)

Yulin Zheng

I'm an undergraduate Computer Science student at UC Berkeley. The tech world always fascinated me with how a breakthrough in one area could influence countless other fields and push their boundaries further.

                    I hope this event will reveal that a single creative idea can become the lifeblood for a constellation of industries, and that the process of coming up with such an idea is as challenging as it is rewarding.

Yipu Zheng

I'm an undergrad at UC Berkeley, majoring in Mechanical Engineering. I believe the best ideas in the world aren't actually in the world yet: they're locked inside people's heads. Events like this one exist to help solve that problem.

                    As an engineer and maker, I understand how many challenges there are in going from an idea to a reality. I hope CRE8 Summit will provide the resources and resolve to overcome these challenges.

DANIEL DANDURAND

I'm a UC Berkeley Physics PhD student interested in making the future awesome. We live in an amazing age where progress in technology can come from existing technology getting amplified by the millions of people experimenting with it.

                    I can't wait to see all the exciting projects people are working on! The more people working on creating new things the more nuggets of gold we will be able to find.

Chinese Team

                        organizing conference on the ground in Shenzhen

Organization and logisitcs in Shenzhen are headed by teams from Tianan Cyber Park and the Player and Maker Space. Their previous experience includes organizing the Shenzhen Silicon Valley Express Meeting, the first in a series of exchanges intended to strengthen ties between the Silicon Valley and Shenzhen business ecosystem.

Thanks to Our
                        Sponsors

Tianan Cyber Park, based in Shenzhen, China, is an investment holding company that supports the development and operation of urban industrial complex. Currently, it provides services to about 4,000 companies specialized in new energy, new materials, biomedicine, software development, electronic information, and environmental protection. Tianan Cyber park aims to foster innovative individuals and companies, and stimulate regional economic development.

China Silicon Valley is a California non-profit corporation committed to promoting investment and business communication and cooperation between China and Silicon Valley.

Shenzhen City Government - Shenzhen was China's first Special Economic Zone and has undertaken important roles in piloting economics reforms. The city has become a fast-growing international metropolis with a burgeoning economy and exciting new investment opportunities.

Huawei is one of the world's largest telecommunications equipment suppliers and the world's third largest smartphone maker. Huawei shipped 75 million smartphones in 2014.

Tencent is a social media and internet company based in Shenzhen. Tencent is the second largest social internet company in the world (after Facebook) with a market cap of over $150 billion. Tencent produces WeChat, the most popular messaging app in China with over 460 million monthly active users.

ZTE is a telecommunications company based in Shenzhen. ZTE established a presence in the United States in 1995 and currently maintains relationships with AT&T, Verizon, Sprint, T-Mobile, and others. The company has established 5 R&D centers in the United States, focusing on 4G technology, Mobile Device technology, and WiMAX, CDMA and LTE related technologies.

Copyright © 2015 Global Create Summit


text:
shared_examples 'remove_estimate quick action' do |issuable_type|
  before do
    project.add_maintainer(maintainer)
    gitlab_sign_in(maintainer)
  end

  context "new #{issuable_type}", :js do
    before do
      case issuable_type
      when :merge_request
        visit public_send('namespace_project_new_merge_request_path', project.namespace, project, new_url_opts)
        wait_for_all_requests
      when :issue
        visit public_send('new_namespace_project_issue_path', project.namespace, project, new_url_opts)
        wait_for_all_requests
      end
    end

    it "creates the #{issuable_type} and interprets estimate quick action accordingly" do
      fill_in "#{issuable_type}_title", with: 'bug 345'
      fill_in "#{issuable_type}_description", with: "bug description\n/remove_estimate"
      click_button "Submit #{issuable_type}".humanize

      issuable = project.public_send(issuable_type.to_s.pluralize).first

      expect(issuable.description).to eq 'bug description'
      expect(page).to have_content 'bug 345'
      expect(page).to have_content 'bug description'
      expect(issuable.time_estimate).to eq 0
    end
  end

  context "post note to existing #{issuable_type}" do
    before do
      visit public_send("project_#{issuable_type}_path", project, issuable)
      wait_for_all_requests
      issuable.update_attribute(:time_estimate, 36180)
    end

    it 'creates the note and interprets the remove_estimate quick action accordingly' do
      add_note("/remove_estimate")

      wait_for_requests
      expect(page).not_to have_content '/remove_estimate'
      expect(page).to have_content 'Commands applied'
      expect(issuable.reload.time_estimate).to eq 0
    end

    context "when current user cannot remove_estimate" do
      before do
        guest = create(:user)
        project.add_guest(guest)

        gitlab_sign_out
        gitlab_sign_in(guest)
        visit public_send("project_#{issuable_type}_path", project, issuable)
        wait_for_all_requests
      end

      it 'does not remove_estimate' do
        add_note('/remove_estimate')

        wait_for_requests
        expect(page).not_to have_content '/remove_estimate'
        expect(issuable.reload.time_estimate).to eq 36180
      end
    end
  end

  context "preview of note on #{issuable_type}", :js do
    it 'explains remove_estimate quick action' do
      visit public_send("project_#{issuable_type}_path", project, issuable)

      preview_note('/remove_estimate')

      expect(page).not_to have_content '/remove_estimate'
      expect(page).to have_content 'Removes time estimate.'
    end
  end
end


text:
using namespace System;
using namespace System::Diagnostics;
using namespace System::Threading;

namespace Examples {
  class Program {
  public:
    // The main entry point for the application.
    static void Main() {
      int index = 0;
      object sync;
      Thread thread((ParameterizedThreadStart)Profile::LockThread);
      thread.Name = "LockThread";
      thread.Start(sync);

      Stopwatch stopWatch;
      stopWatch.Start();
      while (index < Profile::CountMax()) {
        lock_(sync) {
          int cpt = Profile::Counter;
          if (cpt != Profile::Counter)
            Console::WriteLine("cpt != Counter : {0}", cpt + Profile::Counter);
          index++;
        }
      }
      stopWatch.Stop();
      thread.Join();

      Console::WriteLine("Lock Duration : {0}", stopWatch.Elapsed());
    }

  private:
    class Profile : public object {
    public:
      static int CountMax() { return 10000; }
      static int Counter;

      static void LockThread(const Object& sync) {
        for (int index = 0; index < CountMax(); index++) {
          lock_(sync)
          Counter++;
        }
      }
    };
  };
  int Program::Profile::Counter = 0;
}

startup_(Examples::Program);

// This code produces the following output :
//
// Lock Duration : 00:00:00.1326642


text:
from ..mixins.test import TestCaseMixin
from .. import db, models
import datetime
from flask import Flask
from nose.plugins.attrib import attr

class UserTestCase(TestCaseMixin):

    # @attr('single')
    def test_register(self):
        'Testing models.User.register'
        # Create a dummy role
        role1 = models.Role(name="role1")
        role2 = models.Role(name="role2")
        role3 = models.Role(name="role3")
        db.session.add_all([role1, role2, role3])
        db.session.commit()

        user = models.User.register(
            username='alice',
            password='qqq',
            confirmed=True,
            roles=["role1", "role2"],
        )
        user = models.User.query.filter_by(username='alice').first()

        self.assertEqual(user.username, "alice", "Obj attributes readible.")
        self.assertIn(role1, user.roles)
        self.assertIn(role2, user.roles)

    # @attr('single')
    def test_add_system_users(self):
        models.User.add_system_users()
        admin, guest = map(
            lambda username: models.User.query.filter_by(username=username).first(),
            ['admin', 'guest']
        )
        self.assertIn(models.Role.query.filter_by(name="admin").first(), admin.roles)
        self.assertIn(models.Role.query.filter_by(name="guest").first(), guest.roles)


text:
<?php

namespace Spatie\SchemaOrg;

/**
 * Event type: Children's event.
 *
 * @see http://schema.org/ChildrensEvent
 *
 * @mixin \Spatie\SchemaOrg\Event
 */
class ChildrensEvent extends BaseType
{
}


text:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

  <title>ExifTool FAQ</title>
<link rel=stylesheet type='text/css' href='style.css' title='Style'>

Discussion forum

Determining tag names

ExifTool doesn't read/write properly

Aperture and shutter speed

Date and time formats

"Can't convert TAG" errors

Deleting all EXIF from a TIFF

Writing Make, Model & MakerNotes

Tag locations when copying

Coded character sets

User-defined tags

Export to database

Output file size

GPS coordinate format

MakerNote errors

Some files not renamed

List-type tags

Windows character encoding

Formatting tag values

Write errors (repair corrupted EXIF)

Newlines in values

Order of operations

"0 image files updated"

Date/time gets reset to today

Image validation

ExifTool FAQ

1. "Is there a forum for discussing ExifTool issues?"

ExifTool issues can be discussed on the ExifTool forum at
http://u88.n24.queensu.ca/exiftool/forum/

2. "How do I determine the tag name for some information?"

When you run exiftool, by default it prints descriptions, not tag
names, for the information it extracts.  These descriptions are in English
unless the -lang option is used to select another language. Note
that descriptions often contain spaces between words but tag names never do. To
print the tag names instead instead of descriptions, use the -s
option when extracting information.  Valid characters in tag names are
A-Z, a-z, 0-9, _ and
-.  See the tag name
documentation for a complete list of available tag names.

Tag names may be optionally prefixed by a family 0 or 1 group name
to specify a particular information type or location.  Use the
-g0 and -g1 (or
-G0 and -G1) options when extracting
information to see the corresponding group names.

3a. "ExifTool reports the wrong value or doesn't extract a tag",

3b. "ExifTool doesn't write a tag properly", or

3c. "Other software can't read information written by ExifTool"

[Also see FAQ number 23 for reasons why
ExifTool may not write some tags to certain file types.]

First, make sure you are looking at the right information.  Use
ExifTool with a command like this to extract all information from the file,
along with the location it was written:

exiftool -a -G1 -s c:\images\test.jpg

In this command, -a allows duplicate tags to be extracted,
-G1 shows the family 1 group name (ie. the location) of each tag,
and -s shows the tag names instead of their descriptions.
(Substitute the path name of your file in place of
"c:\images\test.jpg".)

When duplicate tags exist, only one is extracted unless the
-a option is used. Beware that options like -EXIF:all
select all EXIF tags from the extracted tags, so EXIF tags hidden by duplicate
tags in other locations will not appear in the output for
-EXIF:all.  For example, the command

exiftool -gps:all image.jpg

will NOT necessarily extract all GPS tags because some GPS tags may have been
suppressed by same-named tags in other groups.  To be sure all GPS tags are
extracted, the -a option must be used:

exiftool -a -gps:all image.jpg

If you are having problems with other software reading information written by
ExifTool, if possible try first writing the information from the other software,
then use ExifTool (with the -a and -G1 options) to
determine where the information was written. Once you know where it should go,
you can use ExifTool to write to this location. You can read or write
information in a specific location by prefixing the tag name on the command line
with the desired group name.  ie) "-ExifIFD:DateTimeOriginal"

This problem may also occur if contradictory information exists in
different meta information formats within the same file.  For example, often XMP
will be ignored if IPTC exists and the Photoshop:IPTCDigest does not agree with
the IPTC content.  The
Metadata Working Group
recommends techniques to keep the EXIF, IPTC and XMP metadata synchronized.
These recommendations are implemented by the ExifTool
MWG tags.  For maximum compatibility with the
widest range of applications, it is suggested that these MWG tags be used
whenever possible.

4. "ExifTool reports more than one shutter speed or aperture value, and
they are slightly different"

There are a number of different ways that aperture and shutter speed information
are stored in many images.  The standard EXIF values (EXIF:FNumber and
EXIF:ExposureTime) should correspond to the values displayed by your camera,
but these values may have been rounded off.  The corresponding EXIF APEX
values (EXIF:ApertureValue and EXIF:ShutterSpeedValue) may be different due
to their own round-off errors.  If available, the MakerNotes values may be
the most accurate because they haven't been rounded off to nice even values
for display, so with these you may see odd values like 1/102 instead of
1/100, etc.

5. "How do I format date and time information for writing?"

All information (including date/time information) is written in the
same format as it is read out.  When reading, ExifTool converts all date and
time information to standard EXIF format, so this is also the way it is
specified when writing.  The standard EXIF date/time format is
"YYYY:mm:dd HH:MM:SS", and some meta information formats such as
XMP also allow sub-seconds and a timezone to be specified.  The timezone format
is "+HH:MM", "-HH:MM" or "Z". For
example:

exiftool -xmp:dateTimeOriginal="2005:10:23 20:06:34.33-05:00" a.jpg

When writing XMP or other information types which allow incomplete date/time
values, the following input formats are also accepted:

YYYY
YYYY:mm
YYYY:mm:dd
YYYY:mm:dd HH:MM

Having said this, ExifTool is very flexible about the actual format of input
date/time values when writing, and will attempt to reformat any values into the
standard format unless the -n option is used.  Any separators may
be used (or in fact, none at all).  The first 4 consecutive digits found in the
value are interpreted as the year, then next 2 digits are the month, and so on.
[The year must be 4 digits.  Other fields are expected to be 2
digits, but a single digit is allowed if the subsequent character is a
non-digit.]  For EXIF date/time values, all 6 date/time fields must exist
("YYYYmmddHHMMSS"), but XMP date/time values require only the year
("YYYY").  This feature facilitates useful operations such as
setting date/time tags from a date embedded in the file name.  For example, the
command

exiftool "-alldates<filename" c:\images

will set the common date/time tags from the file name for all images in the
directory "c:\images".  This will work for any file name which
matches the above criteria (ie. "IMG_20110927_103000.jpg").
[AllDates is a shortcut for 3 tag names: DateTimeOriginal,
CreateDate and ModifyDate.  See the Shortcuts
Tags documentation for more information.]

The -d option allows full control over the format of
date/time values when reading.  However, the effect of the -d
option is not reversible, so date/time values must be written using the format
described above, even when the -d option is used.  Note that when
reading, the effect of the -n option on date/time values is only to
disable the -d formatting.

Special feature: A value of "now" may be used to
represent the current time when writing any date/time tag.  For example:

exiftool -xmp:dateTimeOriginal=now a.jpg

[There is also a Now tag which may
be used for a similar purpose by copying its value to another tag, but copying
tags adds an extra read stage to the processing which is best avoided if
performance is an issue.]

6. "I get 'Can't convert TAG (not in PrintConv)' errors when
writing a tag"

By default, ExifTool applies a print conversion (PrintConv) to extracted
information to make the output more human-readable.  Some conversions involve
lookup tables which are documented in the Values column of the
tag name documentation.  For example, the
GPSAltitudeRef tag defines the following conversions:

0 = Above Sea Level
1 = Below Sea Level

For this tag, a value of '0' is printed as 'Above Sea Level', and '1' is printed
as 'Below Sea Level'.  Reading and writing with ExifTool is symmetrical [with
the possible exception of list-type tags -- see FAQ number 17
below], so a value that is printed as 'Above Sea Level' must also be written in
that form.  (In other words, the inverse print conversion is applied when writing
values.)  For example, to write GPSAltitudeRef you can type:

exiftool -gpsaltituderef="Above Sea Level" image.jpg

or any unambiguous short form may be used and ExifTool will know what you mean, ie)

exiftool -gpsaltituderef=above image.jpg

Alternatively, the print conversion can be disabled for all tags with the
-n option, or for individual tags by suffixing the tag name with a
'#' character.  In either case the printed value of GPSAltitudeRef
will be '0' or '1' when extracting information, and the value is written in the
same way. So following two commands have exactly the same effect as above:

exiftool -gpsaltituderef=0 -n image.jpg
exiftool -gpsaltituderef#=0 image.jpg

Integer values may also be specified in hexadecimal (with a leading '0x').  For
example, the following commands are all equivalent:

exiftool -flash=1 -n image.jpg
exiftool -flash=0x1 -n image.jpg
exiftool -flash#=1 image.jpg
exiftool -flash#=0x1 image.jpg
exiftool -flash=fired image.jpg

Programmers: These techniques look like this when calling Image::ExifTool
functions from a Perl script:

$exifTool->SetNewValue(flash => 1, Type => 'ValueConv');
$exifTool->SetNewValue(flash => 0x1, Type => 'ValueConv');
$exifTool->SetNewValue('flash#' => 1);
$exifTool->SetNewValue('flash#' => 0x1);
$exifTool->SetNewValue(flash => 'fired');

7. "I can't delete all EXIF information from a TIFF file using
'exiftool -exif:all= img.tif'"

This is because of the way a TIFF file is structured.  With a JPEG
image, this command removes IFD0 (the main Image File Directory) as well as any
subdirectories, thus removing all EXIF information.  But with the TIFF format,
the main image itself is stored in IFD0, so deleting this directory would
destroy the image.  The same is true for any TIFF-based RAW file such as DNG,
CR2, NEF, etc.  For these types of files, ExifTool just deletes the ExifIFD
subdirectory, so any information stored in other directories is preserved.

Use "exiftool -a -G1 -s img.tif" to see where the
information is stored.  Any tags remaining in other IFD's must be deleted
individually from a TIFF-format file if desired.  For convenience, a
shortcut tag is provided to simplify the
deletion of common metadata tags from IFD0 by adding "-CommonIFD0="
to the command line.

8a. "All maker note information is lost if I change the Make or Model tag", or

8b. "I can't copy maker note information to an image"

The Make and Model tags are used by some image utilities (including ExifTool) to
determine the format of the maker note information.  Deleting or changing either
of these tags may prevent these utilities from recognizing or properly
interpreting the maker notes.  Also beware that the maker notes information may
be damaged if an image is edited when the maker notes are not properly
recognized. So it is a good idea not to edit the Make and Model tags in the
first place.

If you really want to delete the Make and Model information, you
might as well delete the maker notes too.  You can do this with either of the
following commands:

exiftool -make= -model= -makernotes:all= image.jpg
exiftool -make= -model= -makernotes= image.jpg

For the same reason, maker notes can not be copied to an image with an
incompatible Make or Model.  To do this, the Make and Model tags must also be
copied.  ie)

exiftool -tagsfromfile src.jpg -makernotes -make -model dst.jpg

(Note that in this case the "-makernotes:all" syntax does not work
because it attempts to copy the maker note tags individually.  Since maker note
tags may not be created individually, they must instead be copied as a block
with "-makernotes".)

9a. "The information is different when I copy all tags to a new file", or

9b. "The tag locations change when I use -tagsfromfile
to copy information"

This feature is explained under the -tagsFromFile option in
the exiftool application documentation, but the
question is common enough that it is discussed here in more detail.

By default, ExifTool will store information in preferred locations
when either writing new information or copying information between files. This
freedom allows ExifTool to write or copy information to files of different
formats without requiring the user to know details about where the information
is stored.

The preferred general locations for information written to JPEG
images are 1) EXIF, 2) IPTC and 3) XMP.  As an example, information extracted
from the maker notes will be preferentially written (on a tag-by-tag basis) in
EXIF format when copying information between two JPEG images.  But if a specific
tag doesn't exist in EXIF, then the tag is written to the first valid group in
the order specified above.  The advantage of "translating" the information to
EXIF is that it then becomes readable by applications which only support
standard EXIF.  The disadvantage is that you don't get an exact copy of the
original information structure.

But ExifTool gives you the ability to customize this behaviour to
write the information to wherever you want.  This is done by specifying a group
name for the tag(s) to be copied.  This applies even if the group name is
"all", in which case the original family 1 group is preserved. So
to copy all information and preserve the original structure, use this syntax:

exiftool -tagsfromfile src.jpg -all:all dst.jpg

In this command, since no destination tag was specified, the destination is the
same as the source (ie. "-all:all>all:all"), so the information is
copied to the same family 1 group.

Here are some examples to show you the type of control you have over
where the information is written. All commands in each example are equivalent:

# copy all tags to preferred groups (no destination group)
exiftool -tagsfromfile src.jpg dst.jpg
exiftool -tagsfromfile src.jpg -all dst.jpg
exiftool -tagsfromfile src.jpg "-all>all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all>all" dst.jpg

# copy all tags, preserving family 1 group (destination group 'all')
exiftool -tagsfromfile src.jpg -all:all dst.jpg
exiftool -tagsfromfile src.jpg "-all>all:all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all>all:all" dst.jpg

# copy all tags to EXIF group (destination group 'exif')
# [the destination family 1 group is the preferred EXIF IFD]
exiftool -tagsfromfile src.jpg "-all>exif:all" dst.jpg
exiftool -tagsfromfile src.jpg "-all:all>exif:all" dst.jpg

# copy XMP tags to XMP group (destination group 'xmp')
# [the destination family 1 group is the preferred XMP namespace]
exiftool -tagsfromfile src.jpg "-xmp:all" dst.jpg
exiftool -tagsfromfile src.jpg "-xmp:all>xmp:all" dst.jpg

# copy XMP tags, preserving family 1 group (destination group 'all')
exiftool -tagsfromfile src.jpg "-xmp:all>all:all" dst.jpg

# copy XMP tags to preferred groups (no destination group)
exiftool -tagsfromfile src.jpg "-xmp:all>all" dst.jpg

# copy XMP tags to EXIF only (destination group 'exif')
# [the destination family 1 group is the preferred EXIF IFD]
exiftool -tagsfromfile src.jpg "-xmp:all>exif:all" dst.jpg

The same rules illustrated above also apply when copying individual tags.

Note: If no destination group is specified, a new tag is created if
necessary only in the preferred group, but if the same tag already exists in
another group, then this information is also updated.  (Otherwise inconsistent
values for the same information would exist in different locations. Of course,
you can always generate inconsistencies like this if you really want to by
specifically writing contradictory information to different groups.)

Certain types of meta information (such as EXIF, IPTC, XMP and
ICC_Profile) may also be copied as a block. This technique copies all
meta information, even if ExifTool doesn't have the ability to write some
individual tags contained in the block. For all block types except EXIF, the
metadata is copied byte-for-byte from the original image.  With EXIF however,
the metadata may be restructured to ensure that it is self-contained.  Also note
that EXIF may not be written as a block to TIFF-based file formats.  Beware that
any existing metadata of this type in the distination file will be
overwritten by the new block.

# copy EXIF as a block between same-named JPG files in different directories
exiftool -tagsfromfile SRCDIR/%f.%e -ext jpg DSTDIR

# copy XMP as a block from one file to another
exiftool -tagsfromfile src.jpg -xmp dst.cr2

10. "How does ExifTool handle coded character sets?"

[Also see FAQ number 18 for help on displaying
special characters in a Windows console.]

Certain meta information formats allow coded character sets other
than plain ASCII.  When reading, most known encodings are converted to the
external character set according to the exiftool "-charset CHARSET"
or -L option, or to UTF‑8 by default.  When writing, the
inverse conversion is performed.  Alternatively, special characters may be
converted to/from HTML character entities with the -E option.

A distinction is made between the external character set
visible to the ExifTool user, and the internal character used to store
text in the metadata of a file.  These character sets may be specified
separately as follows:

The external character set for strings passed to/from ExifTool
is UTF‑8 by default, but it may be changed through any of these
command-line options:

-charset CHARSET   or
-charset exiftool=CHARSET   or   -L

The internal character set for strings stored in file metadata may be
specified for some metadata types:

-charset TYPE=CHARSET

(where TYPE is "exif", "iptc",
"id3", "photoshop" or "quicktime")

Valid CHARSET values are (with aliases given in brackets):

UTF8	(cp65001, UTF‑8)	Thai	(cp874)

Latin	(cp1252, Latin1)	MacRoman	(cp10000, Mac, Roman)

Latin2	(cp1250)	MacLatin2	(cp10029)

Cyrillic	(cp1251, Russian)     	MacCyrillic	(cp10007)

Greek	(cp1253)	MacGreek	(cp10006)

Turkish	(cp1254)	MacTurkish	(cp10081)

Hebrew	(cp1255)	MacRomanian	(cp10010)

Arabic	(cp1256)	MacIceland	(cp10079)

Baltic	(cp1257)	MacCroatian	(cp10082)

Vietnam	(cp1258)

The -L option is equivalent to "-charset Latin",
"-charset Latin1" and "-charset cp1252".

Type-specific details are given below about the special character
handling for EXIF, IPTC, XMP, PNG, ID3, PDF, Photoshop, QuickTime, AIFF, MIE and
Vorbis information:

EXIF: Most textual information in EXIF is stored in "ASCII"
format (called "string" in the ExifTool tag name
documentation).  By default ExifTool does not convert these strings.
However, it is not uncommon for applications to write UTF‑8 or other
encodings where ASCII is expected.  To deal with these, ExifTool allows the
internal EXIF string encoding to be specified with
"-charset exif=CHARSET", which causes EXIF string values to be
converted from the specified character set when reading, and stored with this
character set when writing.  (The
MWG recommends using
UTF‑8 encoding for EXIF strings, and in keeping with this the
"-use mwg" feature sets the default internal EXIF string encoding
to UTF‑8, but note that this will have no effect unless the external
encoding is also set to something other than the default of UTF‑8.)

A few EXIF tags (UserComment, GPSProcessingMethod and
GPSAreaInformation) support a designated internal text encoding, with values
stored as ASCII, Unicode (UCS-2) or JIS.  When reading these tags, ExifTool
converts Unicode and JIS to the external character set specified by the
-charset or -L option, or to UTF‑8 by default.
ASCII text is not converted.  When writing, text is stored as ASCII unless the
string contains special characters, in which case it is converted from the
external character set (UTF‑8 by default), and stored as Unicode. ExifTool
writes Unicode in native EXIF byte ordering by default, but the byte order may
be specified by setting the ExifUnicodeByteOrder tag (see the
Extra Tags documentation).

The EXIF "XP" tags (XPTitle, XPComment, etc) are always stored
internally as little-endian Unicode (UCS‑2), and are read and written
using the specified external character set.

IPTC†: The
value of the IPTC:CodedCharacterSet tag determines how the internal IPTC string
values are interpreted.  If CodedCharacterSet exists and has a value of
"UTF8" (or "ESC % G") then string values are
assumed to be stored as UTF‑8.  Otherwise the internal IPTC encoding is
assumed to be Windows Latin1 (cp1252), but this can be changed with
"-charset iptc=CHARSET". When reading, these strings are converted
to UTF‑8 by default, or to the character set specified by the
-charset or -L option. When writing, the inverse
conversions are performed. No conversion is done if the internal (IPTC) and
external (ExifTool) character sets are the same.  Note that ISO 2022 character
set shifting is not supported. Instead, a warning is issued and the string is
not converted if an ISO 2022 shift code is encountered.  See the
IPTC IIM
specification for more information about IPTC character coding.

ExifTool may be used to convert IPTC values to a different internal
encoding.  To do this, all IPTC tags must be rewritten along with the desired
value of CodedCharacterSet.  For example, the following command changes the
internal IPTC encoding to UTF‑8:

exiftool -tagsfromfile @ -iptc:all -codedcharacterset=utf8 a.jpg

and this command changes it back from UTF‑8 to Windows Latin1 (cp1252):

exiftool -tagsfromfile @ -iptc:all -codedcharacterset= a.jpg

or this command changes it back from UTF‑8 to Windows Latin2 (cp1250):

exiftool -tagsfromfile @ -iptc:all -codedcharacterset= -charset iptc=latin2 a.jpg

Note that unless CodedCharacterSet indicates UTF‑8, applications
have no reliable way to determine the IPTC character encoding.  For this reason,
it is recommended that CodedCharacterSet be set to "UTF8" when
creating new IPTC.

† Refers to the older
IPTC IIM format.
The more recent
IPTC
Core and Extension specifications actually use the XMP format (see below).

XMP: Exiftool reads XMP encoded as UTF‑8, UTF‑16
or UTF‑32, and converts them all to UTF‑8 internally.  Also, all XML
character entity references and numeric character references are converted.
When writing, ExifTool always encodes XMP as UTF‑8, converting the
following 5 characters to XML character references: & < > '
". By default no further conversion is performed, however the
-charset or -L option may be used used to convert
text to/from a specified character set when reading/writing.

PNG: PNG TextualData
tags are stored as tEXt, zTXt and iTXt chunks in PNG images.  The tEXt and
zTXt chunks use ISO 8859-1 encoding, while iTXt uses UTF‑8.  When reading,
ExifTool converts all PNG textual data to the character set specified by the
-charset or -L option, or to UTF‑8 by default.
When writing, ExifTool generates a tEXt chunk (or zTXt with the -z
option) if the text doesn't contain special characters or if Latin encoding is
specified (-L or -charset latin); otherwise an iTXt
chunk is used and the text is converted from the specified character set and
stored as UTF‑8.

ID3: The ID3v1 specification officially supports only ISO
8859‑1 encoding (a subset of Windows Latin1), although some applications
may incorrectly use other character sets.  By default ExifTool converts ID3v1
text from Latin to the character set specified by the -charset or
-L option, or to UTF‑8 by default.  However, the internal
ID3v1 charset may be specified with "-charset id3=CHARSET".  The
encoding for ID3v2 information is stored in the file, so ExifTool converts
ID3v2 text from this encoding to the character set specified by
-charset or -L, or to UTF‑8 by default. ExifTool
does not currently write ID3 information.

PDF: PDF text strings are stored in either PDFDocEncoding
(similar to Windows Latin1) or Unicode (UCS‑2).  When reading, ExifTool
converts to the character set specified by the -charset or
-L option, or to UTF‑8 by default.  When writing, ExifTool
encodes input text from the specified character set as Unicode only if the
string contains special characters, otherwise PDFDocEncoding is
used.

Photoshop: Some Photoshop resource names are stored as
Pascal strings with unknown encoding.  By default, ExifTool assumes MacRoman
encoding and converts this to UTF‑8, but the internal and external
character sets may be specified with -charset Photoshop=CHARSET
and -charset CHARSET respectively.

QuickTime: QuickTime text strings may be stored in a
variety of poorly documented formats, and ExifTool does its best to decode
these according to the -charset option setting.  For some
QuickTime strings where the internal encoding is not known, ExifTool assumes
a default encoding of MacRoman, but this may be changed with
"-charset QuickTime=CHARSET".

AIFF: AIFF strings are assumed to be stored in MacRoman, and
are converted according to the -charset option when reading.

MIE: MIE strings are stored as either UTF‑8 or ISO
8859‑1. When reading, UTF‑8 strings are converted according to
the -charset or -L option, and ISO 8859‑1
strings are never converted.  When writing, input strings are converted from
the specified character set to UTF‑8.  The resulting strings are stored as
UTF‑8 if they contain multi-byte UTF‑8 character sequences,
otherwise they are stored as ISO 8859‑1.

Vorbis: Vorbis comments are stored as UTF‑8,
and are converted to the character set specified by -charset or
-L when reading.

Programmers: ExifTool returns all values as byte strings of encoded
characters. Perl wide characters are not used.  The encoding is UTF‑8 by
default, but valid UTF‑8 can not be guaranteed for all values, so the
caller must validate the encoding if necessary.  The encodings described above
are set by the various Charset options of
the API.

Note: Some settings of the system PERL_UNICODE environment
variable may be incompatible with ExifTool's character handling.

11. "My user-defined tags don't work"

For examples of how to add user-defined tags, see the
ExifTool_config file in the ExifTool distribution.
It may be useful to activate this file as a test before trying to implement
your own config file.  To activate this file, copy it to your HOME
directory then rename it to ".ExifTool_config".

Note: The config file must be renamed at the
command line because neither the Windows nor Mac GUI allow a file name to
begin with a ".".  To do this in Windows, run "cmd.exe" and type
the following (pressing RETURN at the end of each line):

cd %HOMEPATH%
rename ExifTool_config .ExifTool_config

or on a Mac, open the "Terminal" application (from the /Applications/Utilities
folder) and type this command then press RETURN:

mv ExifTool_config .ExifTool_config

With the sample config file installed, you should be able to write the example
tags.  A command like this:

exiftool -v2 -NewXMPxmpTag=test FILE

should print this as the first line of its output:

Writing XMP-xmp:NewXMPxmpTag

If this doesn't work, the most common problem is that the
".ExifTool_config" configuration file isn't getting loaded.  In
this case, there are a few things you can try:

Make sure the config file name is correct.  It must be
".ExifTool_config" (note the leading ".", and the
capital "T").

Set either the HOME or the EXIFTOOL_HOME environment variable
to the name of the directory where you put your ".ExifTool_config"
file.

Put the config file in the same directory as the exiftool script.  (Also, be
sure the config filename starts with a dot!  See the note above for help
renaming the config file.)

If you can't get the config file to load automatically, you can try loading
it manually with the exiftool -config CFGFILE option. (Note:
This must be the first option on the command line.)  This allows loading
of a config file with any name.

If necessary, you can verify that ExifTool is loading your config
file by adding the following line to your file:

print "LOADED!\n";

If you see a "LOADED!" message when you run exiftool, but your new
tags still don't work, make sure you are using the proper tag name and that the
file you are writing can support this type of information.

Programmers: To specify the config file directory from within
a Perl script when using the ExifTool API, set the EXIFTOOL_HOME
environment variable before loading the ExifTool module:

BEGIN { $ENV{EXIFTOOL_HOME} = '/config_file_directory' }
use Image::ExifTool;

Also see the Configuration section of the
ExifTool API documentation for techniques to use a config file with another
name, or to disable the config file feature.

12. "How do I export information from exiftool to a database?"

It is often easiest to export information formatted as  a tab-delimited or
comma-separated list of values using the exiftool -T or
-csv option.  As well, the -r option is useful for
recursing through all images in a hierarchy of directories.  For example:

exiftool -T -r -filename -exposuremode -ISO t/images > out.txt

This command recursively processes all images in the "t/images"
directory, extracting FileName, ExposureMode and ISO tags, and writing the
output to a tab-delimited text file called "out.txt". After the
command has executed, "out.txt" will look something like this:

Canon.jpg       Manual  100
Casio.jpg       -       64
Nikon.jpg       -       100
OlympusE1.jpg   Auto    400

One limitation of the -T option is that a list of tags to extract
must be specified.  Otherwise, all information is extracted from each input
file, and the columns would contain values from random tags.

 The -csv (comma separated values) option solves this
dilemma by pre-extracting information from all input files, then producing a
sorted list of available tag names as the first row of the output, and
organizing the information into columns for each tag.  As well, a first column
labelled "SourceFile" is generated.  These features make it practical to use the
-csv option for extracting all information from multiple images.
For example, this command:

exiftool -csv -r t/images > out.csv

gives an output like this:

SourceFile,AEBBracketValue,AELock,AFAreaHeight,AFAreaMode,AFAreas,[...]
t/images/Canon.jpg,0,,151,,,[...]
t/images/Casio.jpg,,,,,,[...]
t/images/Nikon.jpg,,,,Single Area,,[...]
t/images/OlympusE1.jpg,,Off,,,"Center (121,121)-(133,133)",[...]

Note that the number of columns in the -csv output may be very
large if all information is extracted.  Missing tags are indicated by empty
strings as in the example above, or by dashes if the -f option is
used.

 It should be possible to import these files directly into most
database applications.  On the command line, any list of tag names may be used,
and any number of file or directory names may be specified. (Hint: If your
command line starts to get too long, you may want to look into using the
-@ option and/or the ShortCut
feature).

In Windows, a .BAT file containing the exiftool command may be used
to give drag and drop functionality.  Dropping a folder on the following .BAT
file will create "out.txt" in the folder:

echo "FileName<tab>Aperture<tab>ISO" > %1\out.txt
exiftool -T -r -filename -aperture -ISO %1 >> %1\out.txt

The "echo" command was included to add column headings to the
output.  (The tab character in the echo command, indicated by
"<tab>", may be generated in Mac/Linux shells with CTRL-v
then TAB, or in a Windows cmd shell with TAB when cmd.exe is run with the
/f:off option to disable tab completion.)

Other possible export formats include RDF/XML (with the the
-X option), or JSON (with the -j option).  These
methods allow transfer of more complex data sets (including structured
information with the -struct option), but require that the
importing software supports these formats.

Finally, the -p option may be used to generate any
arbitrary output format.  For example, the following format file
(let's call it "my.fmt") may be used to emulate a CSV-formatted
output:

#[HEAD]FileName, Aperture, ISO
$filename, $aperture, $iso

with a command like this:

exiftool -f -r -p my.fmt t/images > out.csv

Alternatively, the -p option may be used with a format string instead
of a file name.  The following command has the same effect as above except that
the row of headings is not printed (Note: Use single quotes as below on Mac/Linux,
or double quotes instead on Windows):

exiftool -f -r -p '$filename, $aperture, $iso' t/images > out.csv

With the -f option, the value of any missing tag is printed as a
dash.  Without this option, missing tags generate a minor warning and the
line in the -p output is not printed.  The -m option
may be used to ignore minor warnings, which causes these lines to be printed
with an empty value for missing tags.

See the -p option in the application
documentation for more information about this feature.

Note:  Information may be imported from CSV or JSON files for
writing to images by specifying an input file name with the -csv or
-j option.  See the exiftool
application documentation for more details.

13. "Why is my file smaller after I use ExifTool to write information?"

There are various specific reasons why this can happen, but the general answer
is:  When ExifTool writes an image, the meta information may be restructured in
such a way that it takes less space than in the original file.

For instance, the EXIF/TIFF standard allows for blocks of
unreferenced data to exist in an image.  Some digital cameras write JPEG or
TIFF-based RAW files which contain large blocks of unused data, usually filled
with binary zeros.  The reason for this could be to simplify camera algorithms
by allowing variable-sized information to be written at fixed offsets in the
output image. When ExifTool rewrites an image it does not copy these unused
blocks.  This can result in a significant reduction in file size for some
images.  [The -htmlDump option may be used to view the file
structure if you are interested in seeing these unused data blocks -- use a
command like "exiftool -htmlDump a.jpg > out.html", then open
out.html in your web browser.  Unused data blocks are
brown in this output.]

Also, the size of an XMP record may easily shrink or grow when it is
rewritten, even if no meta information is changed.  This is partly due to the
fact that the XMP specification recommends a few KB of padding at the end of the
record (ExifTool adds 2424 bytes by default, but this padding is omitted if the
-z option is used), and partly due to the flexibility of the XMP
format which allows the information to be written in various styles, some of
which are more compact than others.

You may also notice that the values of some "offset" tags (like
ThumbnailOffset and PreviewImageStart) may change when the file is rewritten.
This is normal, and simply indicates that the associated data is now stored at a
different position within the file.

ExifTool does not modify the image data itself, so editing a file is
"lossless" as far as the image is concerned.

14. "What format do I use for writing GPS coordinates?"

ExifTool is very flexible in the formats allowed for entering GPS
coordinates.  Any string containing between 1 and 3 floating point numbers is
valid.  The numbers represent degrees, (and optionally) minutes and
seconds.

For EXIF GPS coordinates, the reference direction is specified
separately with the EXIF:GPSLatitudeRef or EXIF:GPSLongitudeRef
tag.

For XMP GPS coordinates, the reference direction is specified within
the XMP:GPSLatitude or XMP:GPSLongitude value, with west longitudes and south
latitudes being specified either by negative coordinate values or by ending the
string with "W" or "S".

Here are some examples of equivalent ways to specify a GPS
latitude in both EXIF and XMP:

exiftool -exif:gpslatitude="42 30 0.00" -exif:gpslatituderef=S a.jpg
exiftool -exif:gpslatitude="42 deg 30.00 min" -exif:gpslatituderef=S a.jpg
exiftool -exif:gpslatitude=42.5 -exif:gpslatituderef=S a.jpg

exiftool -xmp:gpslatitude="42 30 0.00 S" a.jpg
exiftool -xmp:gpslatitude=42.50S a.jpg
exiftool -xmp:gpslatitude=-42.5 a.jpg

Similar styles may be used for longitude.  ExifTool will convert any of these
coordinate styles to the proper format for the specific tag used.

15. "I get MakerNote warnings or errors when reading or writing information"

Problems like this may be caused by image editing software which
doesn't properly update offsets in the MakerNotes when rewriting an image. These
offsets are used as pointers to reference tag values and structures within the
metadata, and errors like this may lead to missing or incorrect values for some
MakerNotes tags.  In many cases, ExifTool will detect this type of problem and
issue a warning like this when reading (or an error when writing):

Warning: [minor] Possibly incorrect maker notes offsets (fix by -340?)

[Be aware that if multiple warnings occur, the -a
option must be used to see them all, since by default only one warning is
displayed per file.]

This is a particularly insidious problem that is sometimes difficult
for ExifTool to correct automagically, so it requires some operator
intervention.  If this warning occurs, you have a few alternatives:

1) Use the -F option to allow ExifTool to attempt to
fix the incorrect offsets.  If ExifTool was correct in its diagnosis, then this
option will fix the incorrect offsets.  This is usually the appropriate choice
if this problem was caused by editing the image with other
software.

2) Use the -m option to ignore the warning (or downgrade
the error to a warning when writing).  This causes ExifTool to honour the
existing maker note offsets, and may be the correct choice if images straight
out of the camera have this problem.

Often, the first choice (-F) is the right thing to do,
but this depends on many factors, so it is best to try both methods then compare
the resulting maker note information to see which works best for your
situation.

When writing, -F applies a permanent correction to the
maker notes.  Note that some MakerNote information may be lost permanently
if the proper correction is not applied when writing images with this
problem.

3) The third alternative is to adjust the maker note offsets by a
specific amount.  This is done by appending an integer to the -F
option. For example, with the warning above (where ExifTool suggests "fix by
-340?"), -F would be equivalent to -F-340.  See the
-F option documentation for
more details.  This advanced feature may require some technical knowledge about
the structure of EXIF information (and here, ExifTool's -htmlDump
feature may be very useful for visualizing this structure).

Other types of MakerNote errors may also prevent the file from
being written.  However, most MakerNote errors are designated as minor,
which allows them to be ignored by using the -m option.  For
example:

Error: [minor] Bad format (65535) for MakerNotes entry 17

Using -m will downgrade the minor error to a warning, allowing the
file to be written, but some MakerNote information may be lost when ignoring
certain types of errors like this.

16. "Why doesn't ExifTool rename my AVI files?"

By default, ExifTool only processes writable file
types† when any
tag‡ is being written and a
directory name is specified on the command line.  To force exiftool to process
other files, they must either be listed on the command line by name, or be
specified using the -ext option, something like this:

exiftool -ext AVI -ext JPG -d pics/%Y/%m "-directory<dateTimeOriginal" DIR

When a single -ext option is used, only files of the specified type
are processed.  However, multiple -ext options may be used in the
same command (as in the example above) to process any number of different file
types.

† The
-listwf option may be used to list the extensions of all writable file types.

‡ This includes "pseudo" tags like
FileName, Directory, FileModifyDate and FileCreateDate.

17. "List-type tags do not behave as expected"

Tags indicated by a plus sign (+) in the
tag name documentation are list-type tags.
Two examples of common list-type tags are
IPTC:Keywords and
XMP:Subject.  These tags may contain multiple
items which are combined into a single string when reading.  (By default,
extracted list items are separated by a comma and a space, but the
-sep option may be used to change this.)  When writing, separate
items are assigned individually.  For example, the following command writes
three keywords to all writable files in directory DIR, replacing
any previously existing keywords:

exiftool -keywords=one -keywords=two -keywords=three DIR

List items are assigned separately, NOT all together, because this would
represent a single keyword:

exiftool -keywords="one, two, three" test.jpg  (WRONG!)

With exiftool version 7.56 or later, the -sep option may be used to
split values of list-type tags into separate items when writing.  For example,

exiftool -sep ", " -keywords="one, two, three" DIR

will store three separate keywords, the same as the first example above. This
feature may also be used to split a tag value into separate items if it was
originally stored incorrectly as a single string:

exiftool -sep ", " -tagsfromfile @ -keywords test.jpg

However, sometimes it is desirable to have list items which contain a comma, and
this is allowed:

exiftool -contributor="Harvey, Phil" -contributor="Marley, Bob" a.jpg

But to distinguish these entries when extracting information, a different list
separator or a different output format must be used.  For instance, the
following command uses "//" to separate list items,

exiftool -contributor -sep "//" a.jpg

and produces an output like this:

Contributor  : Harvey, Phil//Marley, Bob

Alternatively, the -j, -php and -X
options use an output format which preserves the structure of a
list (if -sep is NOT used).

Note that the writing examples above overwrite any values which
already existed in the original file for these tags.  Instead, to add or delete
items from an existing list, use "+=" or "-=" in place
of "=".  For example:

exiftool -keywords+="add this" -keywords-="remove this" DIR

With commands like this, new items are added to the list in place of the first
deleted item, or at the end of the list if no items were removed.

Note: Using "=" is equivalent to "+=" in
any command where the same tag is set with "+=" or
"-=" in another assignment.  (ie. existing items will be preserved
unless specifically deleted with "-=".)

To prevent duplication when adding new items, specific items can be
deleted then added back again in the same command.  For example, the following
command adds the keywords "one" and "two", ensuring that they are not duplicated
if they already existed in the keywords of an image:

exiftool -keywords-=one -keywords+=one -keywords-=two -keywords+=two DIR

When copying list tags using the -tagsFromFile option, items are
copied individually to form proper lists.  However, there is a complication when
copying multiple tags to a single list tag:  Here, any assignment to a tag
overrides earlier assignments to the same tag in the command.  For instance,
this command

exiftool "-keywords<filename" "-keywords<comment" DIR

writes only the value from the Comment tag.  (Note that -tagsFromFile @
is implied by the "<" operation in this command, causing tags to
be copied from the original file.)  This may seem strange, but it prevents
duplicate items from being added to a list when copying a group of tags from a
file containing duplicate information.  Alternatively, the
-addTagsFromFile option may be used to accumulate items when
copying from multiple tags:

exiftool -addTagsFromFile @ "-keywords<filename" "-keywords<comment" DIR

Note that as with "=" in the first three examples above, the
"<" operation of this command overwrites any Keywords that
existed previously in the original file.  To add to or remove from the existing
keywords, use "+<" or "-<".

18. "Special characters don't display properly in my Windows console"

The Windows cmd.exe console uses an MS-DOS encoding by default
(cp437 or something similar, depending on your region).  The exiftool
-charset option may be used to encode the exiftool output for a
specific Windows code page, which may help display some special characters, but
instead it may be better to switch the console to UTF‑8 (the native
ExifTool character encoding). This is especially useful if you are using the
-lang option to translate exiftool output to another language.  To
change the the Windows console to UTF‑8, follow these steps:

Run "cmd.exe" to open a Windows console (select "Run..." from the
Start menu and enter "cmd").

Change the font in the console Properties to any True Type font (ie. "TT
Lucida Console").

Type "chcp 65001" then press RETURN at the command prompt.

The console should now be able to display UTF‑8 characters (cp65001).  But
note that the TT Lucida Console font shipped with Windows, at least my version,
may not be very complete, and doesn't seem to contain Japanese or Chinese
characters.

To permanently set the font, select "Save properties for future
windows" when changing the font Properties.  Also, you can automatically run
"chcp 65001" every time "cmd.exe" is launched by changing the
Windows Registry for the Command Processor: Run "regedit" and put "chcp
65001" into Data field for "HKEY_LOCAL_MACHINE\Software\Microsoft\Command
Processor\Autorun". (Unfortunately, I haven't been able to figure out how to
change the code page for exiftool when launched via the Windows GUI.  If anyone
can figure out how to do this, please let me know.)

On some Windows systems, using UTF‑8 doesn't seem to work. In
this case, a Windows character set may be the best alternative:  For instance,
for Windows Latin1 (cp1252) type "chcp 1252" in the console to
switch to cp1252, then run exiftool with "-charset cp1252" (or
-L).  This same technique can be used for other supported Windows
code pages.

19. "How do I change the format of an extracted tag value?"

The exiftool application has built-in options which allow you to
display numeric values (-n), escape special HTML characters
(-E), and change the date/time (-d) and GPS coordinate
(-c) formats, but sometimes more control is needed over the
formatting of a value...

The -p and -tagsFromFile options provide
an advanced translation feature that allows arbitrary Perl expressions to be
used to modify tag values.  The basic syntax is this:

${TAG;EXPR}

where TAG is the tag name, and EXPR is a Perl
expression acting on the default input variable ($_), which is
initially the original value of the tag.  For example, the following command
sets the FileName from Artist, translating spaces to underlines:

exiftool '-filename<${artist;tr/ /_/}.%e' image.jpg

(Note: Use single quotes as above in Mac/Linux, or double quotes instead
in Windows.)

Another technique is to create a user-defined Composite tag to do
the reformatting. Here is a basic config file that reformats the Artist tag to
provide a new MyArtist tag with the same character translation as the example
above:

%Image::ExifTool::UserDefined = (
   'Image::ExifTool::Composite' => {
       MyArtist => {
           Require => 'Artist',
           ValueConv => '$val =~ tr/ /_/; $val',
       },
   },
);
1; # end

With this config file, an Artist value of "Phil Harvey" yields a corresponding
MyArtist value of "Phil_Harvey".  The ValueConv string may be any valid Perl
expression, and is evaluated to obtain the value for the new tag.  In this
expression, $val represents the ValueConv value of the Require'd
tag.

To activate the config file, it must be named
".ExifTool_config" and placed either in your home directory or in
the same directory as the exiftool application. Note that the file name begins
with a ".", so if you are in Windows or on a Mac you may need to
rename the file from the command line since the GUI might not like file names
beginning with a ".".

User-defined Composite tags have many other features, including the
ability to combine the values of multiple tags.  See the
config file documentation for more details about
user-defined tags, and lib/Image/ExifTool/README in the full distribution for a
complete description of ValueConv features.  Also, a
quick
search of the ExifTool forum should reveal a number of user-defined tag
examples, and there are other good (and often more complex) examples which can
be found in the %Image::ExifTool::Exif::Composite hash of the
lib/Image/ExifTool/Exif.pm source code.

20. "ExifTool won't write an image due to errors"

Minor errors may be ignored using the -m option
(FAQ 15 discusses this with respect to MakerNote errors), but
sometimes there are more serious errors which can't be ignored.  ExifTool may be
used to fix metadata problems in JPEG images by deleting all metadata and
rebuilding it from scratch.  The command looks like this:

exiftool -all= -tagsfromfile @ -all:all -unsafe bad.jpg

where "bad.jpg" is the name of the image that requires fixing. This
command deletes all metadata then copies all writable tags that can be extracted
from the original image to the same locations in the updated image.  The
"Unsafe" tag is a shortcut
for unsafe EXIF tags in JPEG images which are not normally copied.

After repairing an image like this you should be able to write to it
without errors, but note that some metadata from the original image may have
been lost in the process.

Note: ExifTool will not modify the JPEG image data, so if the
image itself is corrupted (ie. if you get a message saying "Not a valid JPEG"),
then ExifTool can not be used to repair the image.

If there are also MakerNote problems in the file, you may want to
add the -F option to the command.  See FAQ 15
for details.  For example, to rebuild the EXIF only and fix the MakerNote
offsets you could do this:

exiftool -exif:all= -tagsfromfile @ -exif:all -unsafe -thumbnailimage -F bad.jpg

Advanced: The byte order of the newly created EXIF is set by the value of
the ExifByteOrder tag.  Since this tag does not belong to the EXIF group, it is
not copied with -exif:all above (but would be copied with
-all:all as in the first example).  If ExifByteOrder is not set
then the byte order is determined by the ordering of the MakerNotes if they are
copied, otherwise big-endian ("MM") byte order is used by default.
ExifByteOrder may be set to a specific value to force a particular byte order
when creating new EXIF (ie. "-ExifByteOrder=II" for little-endian).

21. "How do I read/write values containing newline characters?"

When reading, by default exiftool converts all control characters to
"." to avoid messing up the output formatting, so newlines will appear as a "."
in the output.  The -b option may be used to bypass all output
formatting (except that a line-feed character is inserted between items in a
list), but this may not be appropriate when the values of many tags must be
extracted.  In this case, the formatted output (-p), JSON
(-j), XML (-X) and PHP (-php) options
provide alternative output formats which preserve newlines in values.

When writing, there are a number of options:

In many shells, a newline may be inserted directly in the command
line:

Bourne shells (press RETURN inside a quoted string)

exiftool -comment="line 1
line 2" image.jpg

(Also, in Bourne shells the character sequence $'\n'
may be used for a newline.)

C shells (press "\" then RETURN inside a quoted string)

exiftool -comment="line 1\
line 2" image.jpg

[Unfortunately the Windows cmd shell provides no method to get a
newline (CR/LF in Windows) into the command line.  A linefeed (LF) may be
inserted with CTRL-T, but I have found no way to insert a carriage return
(CR).]

Use the -E option to allow HTML character entities (Note:
In Windows a newline is "&#xd;&#xa;" instead of just
"&#xa;"):

exiftool -E "-comment=line 1&#xa;line 2" image.jpg

Write the tag from the contents of a separate text file:

exiftool "-comment<=file.txt" image.jpg

Use $/ in a redirection expression: (Note: Single quotes
must be used in Mac/Linux shells around arguments containing a dollar sign,
but double quotes are used instead in Windows.  Also note that this technique
is slower since the implied -tagsFromFile adds an extra unnecessary
processing pass to read tags from the file.)

exiftool '-comment<line 1$/line 2' image.jpg

22. "In what order are command-line assignments applied when writing?"

When writing, tag assignments on the command line are queued and
applied together as each target file is processed.  In general, assignments
later on the command line override earlier assignments, but there are
exceptions:

When writing list-type tags (ie. -keywords=one), new values
are accumulated rather than overriding earlier assignments.

When copying values to list-type tags (ie.
"-keywords<filename"), new values are accumulated only if
-addTagsFromFile is used, otherwise they override earlier
assigments if -tagsFromFile is used or implied.

Tags copied with the -tagsFromFile option are assigned in
order, and all together at the point in the command line where the
-tagsFromFile option is located, regardless of whether these tags
are specified immediately after the -tagsFromFile option or later
on the command line.  Remember that "-tagsFromFile @" is implied
unless another file is specified when redirecting information with arguments
like "-DSTTAG<SRCTAG".

 Note: When copying tag values,
adding to lists, or shifting date/time values, the source value is always the
original value found in the file, regardless of any previous assignments.  For
example, the following command sets Subject to the original value of Title in
the file (NOT to "test"):

exiftool -title=test "-subject<title" a.jpg

23a. "Why do I get '0 image files updated' when writing?", or

23b. "ExifTool doesn't write some tags to a file"

There are a few reasons why this may happen:

The value of the tag is not being set correctly.

This may be due to a tag value which can't be converted, in which case you
should warning like this (note: you may need to use the -v3 option
to see the warning if other same-named tags are being set properly by the same
assignment):

Warning: Can't convert IFD0:Orientation (not in PrintConv)

You get this warning if you write an invalid value to a tag which accepts only
specific values.  See the "Values" column in the appropriate table of the
tag name documentation for a list of valid
values for these types of tags.  The value conversion may also be bypassed with
the -n option, allowing numerical values to be written directly.
See FAQ number 6 for more details.

The information type isn't supported by the format of the
target file.

Warnings are NOT generated when a tag isn't written because it is
normal that many tags can't be written when copying between files of different
formats.

Tags are not written if the format of the target file doesn't
support the specific type of meta information.  For example, CRW images do not
support EXIF or IPTC metdata.  Follow the links in the
Supported File Types table for an indication
of the tags supported by your file.  If the tags aren't supported for your file
type, then a metadata sidecar file is an
alternative.

Also note that MakerNotes tags can not be created or deleted
individually, so they can only be written if they already exist in a
file.  The entire MakerNotes must be created or deleted as a block (see
FAQ number 8 for details).

A time value is being shifted but the specified tag doesn't
exist.

For example, -datetimeoriginal+=1 will have no effect unless
the DateTimeOriginal tag exists in the image.

24. "When I write a file the date/time gets reset to today's date"

There is sometimes confusion between date/time values stored in the
metadata of the file itself and date/time values stored in the filesystem (ie.
in the disk directory information).  A command like this may be used to extract
all date/time information with an indication of where it is stored:

exiftool -time:all -a -G0:1 -s c:\images\test.jpg

and should give an output something like this:

[File:System]   FileModifyDate                  : 2009:10:05 20:40:36-04:00
[File:System]   FileAccessDate                  : 2009:10:07 09:22:12-04:00
[File:System]   FileCreateDate                  : 2009:10:05 20:40:36-04:00
[EXIF:IFD0]     ModifyDate                      : 2003:10:31 15:44:19
[EXIF:ExifIFD]  DateTimeOriginal                : 2003:10:31 15:44:19
[EXIF:ExifIFD]  CreateDate                      : 2003:10:31 15:44:19

The -G0:1 option causes the family 0 and 1 group names to be
reported in square brackets for each tag.  Tags labelled "File:System" are
stored in the filesystem, while other tags are stored in the location indicated
inside the metadata of the file itself.

ExifTool's default behaviour is to set all filesystem times to
the current date/time when writing, but the -P option may be
used to preserve the original FileModifyDate. FileAccessDate represents the time
the file was last accessed, and is set to the current date/time whenever any
software (including ExifTool) accesses the file.

On systems where a filesystem creation date is maintained, ExifTool
also sets this to the current date/time when the file is edited.  On Windows the
creation date is accessed through the FileCreateDate tag, and is also preserved
with the -P option if Win32API::File::Time is available.  On
Mac/Linux FileInodeChangeDate is available instead of FileCreateDate, and the
only way to preserve the file creation date is with the
-overwrite_original_in_place option.

For example, commands like this act on common metadata tags, setting
the filesystem modification date/time to the current date/time:

# common metadata date/time tags are incremented by 1 hour, while
# FileModifyDate is set to the current date/time
exiftool -alldates+=1 c:\images

[The AllDates tag is a shortcut which represents the 3 common
metadata date/time tags: DateTimeOriginal, CreateDate and
ModifyDate.]

However, FileModifyDate may be preserved with the -P
option:

# FileModifyDate is not changed
exiftool -alldates+=1 -P c:\images

ExifTool also allows FileModifyDate to be written, which provides full control
over the filesystem modification date/time when writing:

# FileModifyDate is incremented by 1 hour
exiftool -alldates+=1 -filemodifydate+=1 c:\images

# FileModifyDate is set from the value of DateTimeOriginal
# (before DateTimeOriginal is incremented by 1 hour)
exiftool -alldates+=1 "-filemodifydate<datetimeoriginal" c:\images

25. "Can ExifTool be used as an image validator?"

ExifTool is not designed as an image validator.  It does issue
warnings about some of the more important problems in the metadata when
reading, and will often catch more problems when writing, but it does not
attempt to do a full validation.  If you are looking for a validator,
try JHOVE.

Last revised Mar 19, 2013

<-- Back to ExifTool home page


text:
<?xml version="1.0" encoding="utf-8"?>
<PackageDefinition xsi:schemaLocation="http://www.buildamation.com ./Schema/BamPackageDefinitionV1.xsd" name="VisualC" version="10.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.buildamation.com">
  <Description>Microsoft VisualC 2010 support (Express edition)</Description>
  <Dependents>
    <Package name="VisualCCommon" />
    <Package name="WindowsSDK" version="7.0A" />
  </Dependents>
  <BamAssemblies>
    <BamAssembly name="Bam.Core" major="2" minor="0" patch="0" />
  </BamAssemblies>
  <DotNetAssemblies>
    <DotNetAssembly name="System" requiredTargetFramework="4.0.30319" />
    <DotNetAssembly name="System.Xml" requiredTargetFramework="4.0.30319" />
    <DotNetAssembly name="System.Core" requiredTargetFramework="4.0.30319" />
  </DotNetAssemblies>
  <SupportedPlatforms>
    <Platform name="Windows" />
    <Platform name="Linux" />
    <Platform name="OSX" />
  </SupportedPlatforms>
</PackageDefinition>


text:
package org.elasticsearch.index.analysis;

import org.apache.lucene.analysis.CharArraySet;
import org.apache.lucene.analysis.en.EnglishAnalyzer;
import org.elasticsearch.common.inject.Inject;
import org.elasticsearch.common.inject.assistedinject.Assisted;
import org.elasticsearch.common.settings.Settings;
import org.elasticsearch.env.Environment;
import org.elasticsearch.index.Index;
import org.elasticsearch.index.settings.IndexSettings;

/**
 *
 */
public class EnglishAnalyzerProvider extends AbstractIndexAnalyzerProvider<EnglishAnalyzer> {

    private final EnglishAnalyzer analyzer;

    @Inject
    public EnglishAnalyzerProvider(Index index, @IndexSettings Settings indexSettings, Environment env, @Assisted String name, @Assisted Settings settings) {
        super(index, indexSettings, name, settings);
        analyzer = new EnglishAnalyzer(version,
                Analysis.parseStopWords(env, settings, EnglishAnalyzer.getDefaultStopSet(), version),
                Analysis.parseStemExclusion(settings, CharArraySet.EMPTY_SET));
    }

    @Override
    public EnglishAnalyzer get() {
        return this.analyzer;
    }
}


text:
package net.kourlas.voipms_sms.preferences;

import android.app.DatePickerDialog;
import android.content.Context;
import android.preference.Preference;
import android.util.AttributeSet;
import android.widget.DatePicker;
import net.kourlas.voipms_sms.Preferences;

import java.util.Calendar;

@SuppressWarnings("unused")
public class StartDatePreference extends Preference implements DatePickerDialog.OnDateSetListener {
    Preferences preferences;

    public StartDatePreference(Context context) {
        super(context);
        preferences = Preferences.getInstance(context);
    }

    public StartDatePreference(Context context, AttributeSet attrs) {
        super(context, attrs);
        preferences = Preferences.getInstance(context);
    }

    public StartDatePreference(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);
        preferences = Preferences.getInstance(context);
    }

    @Override
    protected void onClick() {
        Calendar calendar = Calendar.getInstance();
        calendar.setTime(preferences.getStartDate());
        new DatePickerDialog(getContext(), this, calendar.get(Calendar.YEAR), calendar.get(Calendar.MONTH),
                calendar.get(Calendar.DAY_OF_MONTH)).show();
    }

    @Override
    public void onDateSet(DatePicker view, int year, int monthOfYear, int dayOfMonth) {
        Calendar calendar = Calendar.getInstance();
        calendar.set(year, monthOfYear, dayOfMonth);
        preferences.setStartDate(calendar.getTime());
    }
}